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ABSTRACT 


The  United  States  Marine  Corps  is  implementing  a  new 
human  resource  system  called  the  Total  Force  Administration 
System  (TFAS) .  Enterprise  and  Enterprise  Resource  Planning 
(ERP)  System  implementations  are  reputed  to  be  difficult 
because  of  the  problems  encountered  by  corporate  America  in 
the  late  1990' s.  This  thesis  conducted  a  review  of 
corporate  enterprise  system  implementations  looking  for 
commonality  in  two  areas:  the  most  frequent  problems 
encountered  and  key  success  factors.  This  thesis  provides 
the  TEAS  leadership  with  issues  of  concern  that  require 
greater  attention  or  research  and  with  key  success  factors 
for  the  TEAS  implementation.  This  thesis  also  reviewed  and 
analyzed  the  preliminary  architecture  for  the  TEAS  project. 
By  leveraging  the  lessons  learned  from  other 
implementations,  it  is  hoped  to  increase  the  chances  of 
success  for  this  project  and  minimize  implementation  pain. 
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I . INTRODUCTION 


Chapter  one  discusses  the  purpose  and  content  of  this 
thesis.  It  also  provides  a  brief  overview  of  the  context, 
premise,  objectives,  research  questions,  methodologies 
used,  scope,  limitations,  assumptions,  and  definitions. 

A .  CONTEXT 

This  thesis  conducts  an  analysis  of  the  Marine  Corps' 
future  human  resource  enterprise  system  initiative  called 
the  Total  Force  Administration  System  or  TFAS . 

The  current  system,  the  Marine  Corps  Total  Force 
System  (MCTFS) ,  is  a  manpower  and  paper  intensive  system. 
The  TFAS  is  the  initiative  that  has  sprouted  from  a  review 
of  the  Marine  Corps  service  model  for  providing  pay  and 
administrative  support  to  individual  Marines  and  to  their 
commands.  The  result  of  this  initial  review  has  been  the 
Marine  Corps  attempt  to  modify  its  current  administrative 
(human  resource)  system  by  adding  a  self-service 
capability.  Adding  this  capability  will  allow  the  Marine 
Corps  to  reengineer  its  business  processes  and  eliminate 
the  middleperson,  the  administrative  clerk,  between  the 
individual  Marine  and  his  or  her  personal  file.  This  self- 
service  capability  will  streamline  the  data  flow  into  the 
current  backend  system.  This  self-service  capability  is 
envisioned  to  include  a  Web  portal  and  a  call-center  with 
interactive  voice  response  (IVR) .  The  Web  portal  and  IVR 
will  be  the  front  end  of  a  call  center.  The  call  center 
will  be  tied  to  the  Marine  Corps  Total  Force  System 
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(MCTFS) ,  the  backend  system  for  Marine  Corps  administration 
since  the  early  1980s.  Administration  capabilities  will 
be  spread  over  five  levels  vice  the  three  levels  currently 
used.  The  five  levels  will  be:  the  individual  Marine, 
small  unit  leadership,  the  command.  Personnel 
Administration  Centers  (PACs),  and  higher 
headquarters / disbursing . 

The  vision  for  TFAS  as  stated  by  Lieutenant  Colonel 
(LtCOl)  J.M.  Peterson  is  "to  markedly  improve  and  modernize 
pay  and  administrative  support  while  significantly  reducing 
the  number  of  Marines  needed  to  provide  that  support." 
[Ref.  1]  The  individual  Marine  will  be  given  more 
responsibility  and  the  means  for  maintaining  his  own 
record . 

The  TFAS  must  leverage  existing  and  emerging 
technologies,  reengineer  administrative 
processes,  conserve  precious  manpower  resources 
and  markedly  improve  the  quality  of 
administrative  support.  In  the  short  term,  the 
TFAS  is  designed  to  provide  all  Marines  immediate 
access  via  multiple  avenues  to  their  personal 
administrative  data.  In  the  long  run,  TFAS  is  to 
become  the  enterprise  system  for  conducting  all 
personnel  administrative  business  within  the 
Marine  Corps.  The  TFAS  should  improve  the 
quality  of  administrative  support  provided  to 
Marines  throughout  the  wide  spectrum  of 
environments  that  we  work  in.  [Ref.  1] 

Additionally,  the  TFAS  must  free  up  limited  manpower, 
and  provide  a  reach-back  capability  that  makes  personnel 
administration  compatible  with  our  doctrine  of  Operational 
Maneuver  from  the  Sea  (OMFTS),  thus  reducing  the  footprint 
physically  required  on  the  battlefield.  This  must  be  done 
while  simultaneously  keeping  the  Marine  Corps  on  track  for 
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compatibility  with  future  Department  of  Defense  (DoD) 
initiatives  such  as  the  Defense  Integrated  Military  Human 
Resources  System  (DIHMRS)  . 

The  15  major  requirements  for  the  TFAS  are  outlined 
in  the  preliminary  assessment  [Ref.  2]  as: 

•  Commanders,  small  unit  leaders,  and  training 

managers  must  be  able  to  collect,  pass,  and 
report  pay  and  personnel  information  from  the 
point  of  action 

•  Commanders,  small  unit  leaders,  and  training 

managers  must  be  able  to  authenticate  and  upload 
selected  transactions  reflecting  captured  pay  and 
personnel  information  directly  into  MCTFS  without 
additional,  intermediate-level  processing. 

•  Commanders,  small  unit  leaders  and  training 

managers  must  have  electronic  download  access  to 
pay  and  personnel  information. 

•  Marines  must  be  able  to  review  pay  and 
administrative  information  and  to  conduct 
associated  transactions  without  having  to  be 
physically  co-located  with  the  service  provider 
(administration  unit) .  The  importance  of  the 
geographic  locations  of  the  Marine  needing 
support  and  the  service  provider  must  be 
eliminated . 

•  The  system  must  authenticate  users'  identities. 

•  The  system  must  allow  users  to  sign  documents  in 
a  paperless  environment. 

•  Marines  must  receive  verification  of  their 
completed  transaction  with  an  estimated  date  on 
which  that  transaction  will  affect  the  Marines 
pay  or  other  records . 

•  Commanders  must  be  informed  of  those  transactions 
that  are  submitted  through  a  self-service  or  Call 
Center  capability. 

•  Commanders  must  be  able  to  collect,  quality 
control  (QC) ,  and  forward  pay  and  personnel 
information  to  a  regional  Personnel 
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Administration  Center  (PAC)  for  final  review, 
certification  and  processing. 

•  Pay  and  personnel  information  forwarded  from 

commanders  must  not  require  re-keying  or 
manipulation  once  it  arrives  at  the  regional  PAC. 

•  The  regional  PAC  must  be  able  to  receive  and 

process  transactions  from  the  commanders  they 
support  and  any  commander  in  the  Corps  in  case  of 
contingencies . 

•  The  regional  PAC  must  provide  supported 

commanders  with  feedback  reports  that  alert  them 
to  various  information  or  action  required 
relative  to  their  Marines. 

•  The  paper  service  record  book  and  officer 

qualification  record  must  be  eliminated.  All  pay 
and  personnel  information  must  be  stored 
electronically  in  either  the  Marine's 

pay/personnel  record  in  the  MCTFS  or  in  the 
Official  Military  Personnel  File  (OMPF)  record 
maintained  by  the  Commandant  of  the  Marine  Corps- 
Personnel  Management  Support  Branch  (CMC-MMSB) . 

•  The  system  must  provide  adequate  information 

security  to  resist  and  otherwise  prevent 
electronic  attacks  and  other  system  misuses  and 
abuses  . 

•  Technical  knowledge,  rules,  and  edits  must  be 
built  into  the  system  to  minimize  the  training 
requirements  for  users  and  to  enhance  self- 
service  actions.  This  also  includes  maximum  use 
of  plain  language  vice  codes. 

An  implied  requirement  is  that  the  TFAS  be  compatible 
with  current  and  future  DoD  initiatives.  The  DoD 

initiative  with  the  most  impact  on  the  TFAS  is  the  Defense 
Integrated  Military  Human  Resources  System  (DIHMRS) 
initiative.  The  objectives  and  requirements  for  the  DIHMRS 
are  as  follow. 

•  Must  be  a  fully  integrated  personnel  and  pay 
system  that  allows  for  one-time  entry  that 
updates  all  personnel  and  pay  transactions. 
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•  Include  existing  functionality  of  the  17  current 
legacy  systems  in  use  DoD  wide. 

•  Provide  standard  data  and  data  requirements. 

•  Provide  flexibility  to  include  service  specific 
modules  where  needed 

•  Use  a  commercial  or  government  off  the  shelf 
software 

The  TFAS  implementation  is  currently  scheduled  to 
happen  in  four  phases,  spread  over  eight  or  more  years. 
The  TFAS  is  currently  in  the  first  stage,  normally  called 
the  Concept  Exploration  Phase.  However,  the  Marine  Corps 
has  already  started  to  implement  many  of  the  requirements 
that  would  normally  be  accomplished  in  later  phases  in  a 
traditional  development  or  acquisition  program.  Thus,  it 
would  not  be  accurate  to  call  Phase  I  of  this  program. 
Concept  Exploration.  With  the  TEAS  initiative,  the  Marine 
Corps  is  attempting  to  leverage  available  technology  and 
tie  it  to  its  existing  technology  to  create  a  new  human 
resources  system  that  will  be  less  manpower  intensive  and 
more  scalable. 

The  TEAS  initiative  will  focus  on  the  following  areas 
to  enable  Marine  Self-Service.  There  are  other  initiatives 
and  process  improvements  that  have  been  proposed  for 
phasing  into  the  program  that  are  not  directed  toward 
Marine  Corps  Self-Service.  The  forms  and  processes  that 
will  be  brought  to  the  Web  are: 

•  Servicemen's  Group  Life  Insurance  (SGLI) 

•  Income  Tax  W4 

•  Tricare  Enrollment 

•  W-2  Eorm 

•  DEERS  Eorm 
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•  Dependent  Application  Form  10922 

•  Request  for  Waiver  of  Indebtedness 

•  Combined  Federal  Campaign  (CFC)  Allotments 

•  Reenlistment /Extension  Requests 

•  Lateral  Move  Requests 

•  MCI  Course  Registration  Requests 

•  Separation/Retirement /Resignation  Requests 

•  Tuition  Assistance  Requests 

•  Name  Change  Request 

•  Master  Brief  Sheet  Review 

•  Benefits  Waiver 

•  Personal  Awards  Process  Program 

•  Audit  capabilities  such  as:  Basis  Individual 

Record/Basic  Training  Record  (BIR/BTR) ,  Record  of 
Emergency  Data  (RED) ,  Latest  Leave  and  Earnings 
Statement  (LES) ,  Career  Retirement  Credit  Report 
(CRCR) ,  and  Basic  Allowance  for  Housing) 

Certification. 

Eigure  1,  2,  3,  and  4  below  are  diagrams  that 
demonstrate  and  compare  the  current  administration 
processes  against  the  proposed  processes  after  the  TEAS 
implementation.  Eigure  1  demonstrates  how  the  new  process 
eliminates  steps,  time,  and  the  middleman  from  current 
processes . 
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Figure  1  .  Comparison  of  Existing  and  Recommended  Processing 

From  Ref.  [2] 


Figures  2  and  3  are  my  representations  of  the  current 
process  based  on  my  last  experiences  as  a  Marine  Corps 
administrator.  These  figures  show  some  additional  steps 
that  are  not  in  Figure  1  . 
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Figure  2  . 


Current  Administration  Process 


Figure  3.  Proposed  Administration  Process 


Figures  4  and  5  are  data  flow  diagrams  that 
demonstrate  how  the  number  of  levels  of  interaction  with 
the  system  will  increase  from  two  to  five  with  the  TFAS 
implementation.  The  diagrams  also  show  that  the  system 
will  now  have  to  be  reengineered  to  add  more  approval 
safeguards  into  the  system  whereas  the  current  system 
requires  approval  of  data  prior  to  input. 


Cciecl/REpaie^AppDve 


Figure  4.  "As  Is"  Operational  Architecture  From  Ref.  [2] 
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Figure  5.  "To  Be"  Operational  Architecture  From  Ref.  [2] 

Some  of  the  processes  that  will  be  reengineered  as  a  part 
of  the  TFAS  include,  separations,  audits,  and  personal 
requests . 

As  mentioned  previously,  the  TFAS  does  not  address  any 
changes  to  the  MCTFS.  The  Marine  Corps  believes  that  the 
MCTFS  should  and  will  be  addressed  as  part  of  the  DIHMRS 
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initiative  and  that  the  TFAS  will  work  regardless  of  the 
backend  system,  whether  that  system  is  the  MCTFS  or  the 
DIHMRS.  The  DIHMRS  was  scheduled  to  be  operational  by 
January  2002  but  is  currently  behind  the  original  schedule 
established  by  DoD.  The  DoD  awarded  the  DIHMRS  contract  to 
PeopleSoft  less  than  one  month  ago  during  August  2001. 
[Ref.  3]  The  article  also  states  the  following: 


PeopleSoft  said  the  Defense  Department  would 
purchase  the  PeopleSoft  8  Human  Resources 
Management  System  (HRMS)  to  consolidate  several 
legacy  applications  for  payroll  and  human 
resources.  By  consolidating  the  systems  of  all 
military  branches  and  making  records  available  to 
military  personnel  over  the  Internet,  the  Defense 
Department  hopes  to  save  money  and  improve 
efficiency  in  providing  information  to  servicemen 
and  women.  DIHMRS  will  cut  costs  by  allowing 
military  personnel  to  easily  check  their  own 
records  around  the  clock  without  the  intervention 
of  the  department's  personnel  in  many  cases. 

[Ref.  3] 

The  Marine  Corps  contracted  Klynveld  Peat  Marwick  and 
Goerdeler  (KPMG)  consulting  to  analyze  its  current 
technical  architecture  and  several  administrative  processes 
to  determine  inefficiencies  and  establish  a  baseline  or  the 
real  costs  in  terms  of  time,  manpower,  and  money.  At  the 
same  time,  PricewaterhouseCoopers  was  hired  to  document  the 
best  business  practices  of  the  Marine  Corps  and  to 
recommend  processes  that  should  be  considered  for 
reengineering.  According  to  the  PricewaterhouseCoopers 
analysis,  there  is  a  commonality  between  the  human  resource 
functions  and  processes  of  the  Marine  Corps  and  other 
organizations  that  could  be  leveraged  to  facilitate  easier 
process  reengineering  in  those  initiatives. 
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Additionally,  the  Marine  Corps  established  a  Quality 
Leadership  Board  and  a  Total  Force  Administration  Steering 
Group  to  oversee  and  ensure  success  of  the  initiative. 
These  two  groups  organized  the  best  and  brightest  minds 
from  the  administrative  community  and  the  technical 
community  to  mirror  the  work  being  done  by  the  consultants. 
They  organized  a  test  bed  for  new  and  promising  ideas.  The 
program  manager  for  the  Marine  Corps,  Lieutenant  Colonel 
(LtCol)  Gaskin  says,  "The  success  or  failure  of  TFAS  is 
dependent  upon  the  Corps'  program  management  approach, 
prioritization,  scope,  and  management  of  operator 
expectations."  [Ref.  4] 

B.  PREMISE 

The  premise  of  this  thesis  is  that  the  TFAS  initiative 
can  benefit  from  looking  at  the  challenges,  mistakes,  and 
lessons  learned  endured  by  corporate  America.  Applying 
those  lessons  learned  to  the  TFAS  implementation  will 
increase  the  initiatives  chance  of  success.  Additionally, 
the  initiative  can  benefit  from  a  comparison  of  the 
proposed  architecture  for  the  TFAS  against  proven  methods 
and  standards  of  architecting  an  enterprise  system. 

C .  OBJECTIVE 

The  areas  that  this  thesis  focuses  on  are  enterprise 
architecture,  enterprise  system  implementation,  and  how  the 
Marine  Corps  can  leverage  the  lessons  learned  from  other 
enterprise  implementations  to  ensure  success  of  the  TFAS. 
Therefore,  the  objective  of  this  thesis  is  two-fold.  The 

first  objective  is  to  evaluate  enterprise  resource  systems 
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implementations  of  American  corporations  and  to  create  a 
list  of  lessons  learned  from  that  could  be  applied  to  the 
implementation  of  TFAS  in  the  Marine  Corps.  The  second 
objective  is  to  review  the  proposed  architecture  of  the 
TFAS  enterprise  system.  Architecture  here  refers  to  the 
set  of  processing  components  and  processes  of  the  system 
that  represents  a  common  approach. 

D .  RESEARCH  QUESTION 

The  research  conducted  during  the  course  of  this 
thesis  is  intended  to  answer  two  main  questions: 

•  Can  the  Marine  Corps  leverage  the  lessons  learned 
from  other  Enterprise  Resource  Planning  (ERP) 
implementations  to  achieve  a  higher  level  of 
success  with  fewer  problems? 

•  Does  the  architecture  of  the  TEAS  as  currently 
proposed  have  any  apparent  shortcoming? 

To  better  support  the  main  questions,  other  questions 
that  will  be  answered  are: 

•  What  are  the  characteristics  of  a  successful  ERP 
implementation? 

•  Are  there  any  metrics  that  can  be  used  to 
classify  an  ERP  implementation  as  successful  or  a 
failure? 

•  What  are  the  common  mistakes  made  during 

corporate  ERP  implementations  ? 

•  What  lessons  learned  from  American  corporations 
can  be  applied  to  the  TEAS? 
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•  Historically,  what  are  the  major  hurdles  of  an 
ERP  implementation? 

•  Are  there  any  ERP  implementations  that  closely 

resemble  the  TEAS  plan? 

•  Are  there  any  deficiencies  in  the  TEAS  plan? 

•  Is  the  TEAS  concept  a  valid  concept?  Is  it 

achievable  ? 

•  Is  TEAS  scalable? 

•  Does  TEAS  fit  into  the  future  Joint  DoD 

architecture? 

•  What  are  the  Key  Success  factors  for  TEAS? 

•  Are  there  any  overarching  architectural  or 

implementation  issues  that  have  been  overlooked? 


E.  SCOPE  OF  THESIS 

This  thesis  reviews  the  proposed  architecture  and  the 
implementation  of  the  TEAS.  Concurrently,  this  thesis 
focuses  on  previous  enterprise  system  implementations  for 
similarities  or  for  lessons  learned  that  might  be 
beneficial  to  the  TEAS  program  management.  This  does  not 
include  a  detailed  analysis  of  individual  or  internal 
Marine  Corps  Personnel  Administration  or  the  TEAS 
processes.  Additionally,  this  thesis  will  also  make 
recommendations  as  to  areas  of  further  thesis  study  that 
could  benefit  the  TEAS  implementation. 
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F.  LIMITATIONS  OF  THESIS 

Literature  reviewed  for  the  TFAS  in  this  thesis  were 
preliminary  documents  on  preliminary  documents  and  thus 
many  topics  are  mentioned  in  concept  only  without  details 
being  provided  in  the  actual  documentation.  Some  of  the 
issues  that  were  glanced  over  include  security, 
communication  platform  (s),  and  design  architecture  ( s )  .  I 
was  unable  to  acquire  copies  of  the  formal  technical 
architecture  study  to  give  a  complete  analysis  of  the  TFAS 
architecture.  Therefore,  I  reviewed  the  preliminary 
architectural  documents  that  were  provided.  Additionally,  I 
have  been  unable  to  contact  my  Marine  sponsor  to  clarify 
questions  or  to  gain  additional  information.  This  thesis 
will  proceed  with  the  information  as  contained  in  the 
aforementioned  preliminary  documents. 

This  thesis  will  not  examine  in  detail  the  call  center 
or  IVR  technology  proposed  by  the  TFAS.  Call  center  and 
interactive  voice  response  technology  are  both  mature 
technologies  with  histories  of  smooth  implementations. 
Both  of  these  topics  could  however  be  included  in  follow-on 
research  . 

G.  ASSUMPTIONS 

This  thesis  assumes  that  the  baselines  established  by 
KPMG  and  PricewaterhouseCoopers  to  be  accurate  and  that  all 
information  posted  on  the  official  TFAS  Website  or  provided 
by  the  program  manager  to  be  the  official,  latest,  and  most 
accurate  information  on  the  TFAS  initiative.  The  baselines 
revolve  around  costs  and  benefits  of  the  current  system 
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upon  which  cost-to-benef it  analysis  of  the  alternatives 
were  developed. 


H .  METHODOLOGY 

This  thesis  will  utilize  the  archival  research  method. 
The  archival  research  method  involves  analyzing  case 
studies  and  articles  of  Enterprise  Resource  Planning  (ERP) 
system  implementations  in  American  corporations.  Case 
studies  are  evaluated  for  similarities  to  the  TEAS 
initiative  and  for  general  lessons  learned  that  possibly 
could  apply. 


I.  DEFINITIONS  AND  ABBREVIATIONS 


The  following  definitions  and  abbreviations  are 
defined  as  found  in  the  TEAS  documentation  for  the  purpose 
of  consistency. 

Architecture:  structure  of  components,  their 
relationships,  and  the  principles  and  guidelines 
governing  their  design  and  evolution  over  time. 

[Ref.  5] 

Defense  Integrated  Military  Human  Resources 
System  (DIMHRS)  :  DIMHRS  is  to  provide  a  fully 
integrated  military  personnel  and  pay  capability 
for  all  Components  of  the  Military  Services  of 
the  DoD  to  overcome  shortcomings  in  legacy 
systems.  [Ref.  2] 

E-business:  improves  business  performance  by 
using  electronic  information  technologies  and 
open  standards  to  connect  suppliers  and  customers 
at  all  steps  along  the  value  chain.  The  early 
stages  of  a  company's  e-business  effort  are 
almost  always  focused  on  reaching  the  customer. 
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the  later  stages  on  streamlining  value-chain 
activities  to  deliver  more  value  to  the  customer. 
[Ref.  6] 


Electronic  Data  Interchange  (EDI)  :  EDI  represents 
an  early  form  of  e-commerce  built  on  essentially 
proprietary  technology.  Available  long  before  the 
Internet  achieved  wide  usage,  EDI  attempted,  but 
failed,  to  become  a  computing  standard  that  would 
allow  non-compatible  computers  to  share 
information.  Today,  the  Internet  combined  with  e- 
commerce  is  replacing  it.  [Ref.  7] 

Enterprise  Resource  Planning  (ERP) :  integrates 
the  management  functions  within  a  company  such  as 
logistics,  financial  and  human  resources /payroll 
to  enable  enterprise-wide  management  of 
resources.  [Ref.  6]  The  term  "information 
resources  management"  is  more  appropriate  for  the 
military . 

Extensibility:  The  ability  to  extend  an 
application  to  other  enterprise  systems; 
specifically  the  data  warehouse.  [Ref.  6] 

Information  Resources  Management:  the  process  of 
managing  information  resources  to  accomplish 
agency  missions.  The  term  encompasses  both 
information  itself  and  the  related  resources, 
such  as  personnel,  equipment,  funds,  and 
information  technology.  [Ref.  8] 

Joint  Technical  Architecture  (JTA) :  Identifies  a 
common  set  of  mandatory  information  technology 
standards  and  guidelines  to  be  used  in  all  new 
and  upgrade  acquisitions.  [Ref.  2] 


Marine  Corps  Total  Force  System  (MCTFS) :  The 

MCTES  is  an  integrated  personnel  and  pay  system. 
The  Einance  Systems  Activity  (ESA)  at  the  Kansas 
City  Center  maintains  the  MCTES  central  database, 
which  contains  all  of  the  MCTFS  data  elements. 
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This  file  is  commonly  referred  to  as  the  Central 
Master  File  (CMF) .  The  CMF  is  comprised  of  more 
than  500,000  records  containing  specific  data 
file  elements  of  all  Active/Reserve  Marine 
personnel.  These  records  are  available  to 
commanders  and  administrators  throughout  the 
Marine  Corps  for  pay  purposes,  personnel 
management,  or  personnel  management  reporting. 
Use  of  this  information  facilitates  procurement, 
training,  assignment/mobilization,  promotions, 
budget  preparation,  and  pay  service.  [Ref.  9] 

Marine  OnLine  (MOL) :  The  MOL  was  envisioned  as  a 
way  to  strengthen  the  Marine  Corps  community,  to 
enhance  communication  among  every  member  of  the 
enterprise,  and  to  build  a  sense  of  connectivity 
that  extends  beyond  geographic  boundaries. 
Similar  in  concept  to  popular  commercial  Web- 
based  services,  the  MOL  is  a  Web-based  system 
that  facilitates  the  collection,  organization, 
processing,  and  presentation  of  information. 
[Ref.  2] 

On-Line  Diary  System  (OLDS) :  OLDS  is  an 
input/output  (I/O)  system  that  supports 
Headquarters  Marine  Corps  (HQMC)  ,  other  higher 
headquarters  elements,  and  their  supporting 
establishment  (e.g.,  non-Fleet  Marine  Force  (FMF) 
commands) .  The  system  requires  on-line 
connectivity  to  the  mainframe-processing  site  at 
the  mega  center  in  St.  Louis,  Missouri.  OLDS  is  a 
class  IB  system  that  provides  a  primary  method  of 
data  entry  into  MCTFS .  OLDS  is  a  self-prompting 
system  that  allows  the  operator  to  choose  various 
commands  for  data  entry  and  retrieval.  This  allows 
the  MCTFS  diary  and  payroll  transactions  to  be 
prepared,  reviewed,  deleted,  certified, 
decertified,  and  printed.  [Ref.  9] 

Operations  Architecture:  Operations  architecture 
is  a  combination  of  tools,  support  services, 
procedures,  and  controls  required  to  keep  a 
production  system  up  and  running  well.  [Ref.  10] 

Operational  Data  Store-Enterprise  (ODSE) : 
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Operational  Data  Store  (ODS)  is  an  infinitely 
extensible,  universal  repository  that  contains 
functionally  independent,  functionally  dependent, 
relational,  hierarchical  and  aggregate  data.  ODS 
data  is  both  current  and  historical  and  is 
stored,  normalized,  on  the  ODS  server.  This 
relational  architecture  is  a  staging  area  that 
supports  data  quality  assurance,  data  mining  and 
the  production  and  management  of  data  warehouses, 
data  marts,  new  application  databases,  and  feeds 
to  other  organizations.  There  is  no  user  access 
to  the  ODS.  [Ref.  11] 

Technical  Architecture  Framework  for  Information 
Management  (TAFIM) :  The  TAFIM  is  a  set  of 

documents  produced  by  DoD  to  guide  information 
systems  toward  open  systems  architecture.  It 
provides  the  services,  standards,  design 
concepts,  components  and  configurations  that  can 
be  used  to  guide  the  development  of  technical 
architectures.  [Ref.  2] 

Total  Force  Administration  System  (TFAS) :  The 

TFAS  initiative  is  a  comprehensive  effort  to 
modernize  the  Marine  Corps  service  model  for 
providing  pay  and  administrative  support  to 
commanders  and  Marines.  This  modernization 
effort  includes  a  review  of  the  role  of  the 
commander,  the  role  of  the  individual  Marine, 
organizational  structure,  processes  and 
technology.  [Ref.  4] 

Unit  Diary/Marine  Integrated  Personnel  System 
(UD/MIPS) :  The  commander's  personnel  and  pay 
reporting  and  retrieval  system  that  can  be  used 
from  any  location  worldwide.  The  UD/MIPS  is  a 
state-of-the-art  application  that  is  scaleable  to 
support  the  entire  spectrum  of  reporting 
environments  --  for  both  the  active  and  reserve 
components  of  the  Marine  Corps.  [Ref.  9] 
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II.  HISTORY  OF  ENTERPRISE  SYSTEMS 


"Computing  has  always  been  about  extending  human 
capabilities,"  says  Mark  Goodyear.  [Ref.  10]  Figure  6 
below  is  a  graphical  representation  of  the  advances 
computing  has  made  over  the  past  40  plus  years,  with  at 
least  one  major  platform  in  each  decade. 


1980’s 


/ 

\ 

Netcentric 

2000 

FTl 

Client/ 

Server 

1990’s 

DBMS 

Figure  6.  History  of  Computer  Systems  From  Ref.  [10] 


A.  BATCH  COMPUTING 

The  1960' s  were  the  decade  of  batch  computing.  In 
batch  computing,  the  system  would  process  a  group  of 
transactions  submitted  together  without  user  intervention. 
At  the  end  of  the  processing,  at  some  point,  the  computer 
would  provide  a  report  about  the  batch  and  list  any  errors. 
The  report  (s)  would  be  batch  printed  on  a  daily  or 

scheduled  basis.  Any  items  listed  on  the  batch  report  as 
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errors  would  have  to  be  resubmitted  after  proper  research 
and  correction  of  the  error. 


B .  ONLINE  TRANSACTIONS 

The  1970' s  were  the  decade  of  on-line  transactions. 
Online  transactions  allowed  the  user  to  submit  transactions 
one  at  a  time  and  receive  immediate  verification  as  to  the 
success  or  failure  of  the  transaction.  Additionally, 
online  transactions  allowed  all  concerned  to  know  the 
impact  of  the  transaction.  This  changed  the  workflow  of 
business  and  had  an  impact  of  how  business  was  conducted. 
Later  in  the  decade,  the  advent  of  on-line  interactive 
systems  allowed  for  businesses  to  communicate  internally 
and  with  each  other  through  wide  area  networks  which  had 
its  beginning  in  this  decade  also. 

C.  DATABASES  AND  DATABASE  MANAGEMENT  SYSTEMS 

The  1980' s  was  the  decade  of  databases  and  database 
management  systems  (DBMSs) .  Databases  and  database 
technology  had  been  used,  developed  and  implemented  by 
corporations  in  the  1970' s,  but  it  was  not  until  the  1980's 
that  corporations  began  attempting  to  share  data  across 
organizational  and  application  boundaries.  [Ref.  10] 
Database  technology  did  not  change  the  way  business  was 
conducted  per  se;  what  it  did  for  business  was  to  make  it 
more  convenient  to  access  data  and  "ensure  it  was  updated 
while  maintaining  the  integrity  of  the  data."  [Ref.  10]  Up 
to  this  point,  large  database  systems  were  usually  written 
in  COBOL;  adding  a  field  to  a  record  or  changing  the  byte 
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length  of  a  data  field  required  major  overhaul.  The  DBMSs, 
particularly  relational  ones,  eliminated  that  problem  and 


enabled  a  lot  more  prototyping.  This  was  only  a  back- 
office  improvement  and  did  not  change  the  interface  with 
the  system. 

D.  CLIENT/SERVERS 

The  1990' s  ushered  in  the  decade  of  client/server 
technology.  The  implementation  of  client/server  technology 
represented  a  major  fundamental  change  in  computing.  The 
first  change  with  client/server  computing  was  that  a 
transaction  could  now  be  processed  on  a  keystroke-by- 
keystroke  basis,  which  represented  a  change  in  the  level  of 
interaction  between  the  user  and  the  computer.  Secondly, 
client/server  computing  facilitated  communication  in 
workgroups  on  local  area  networks  (LAN)  at  speeds  of  100  to 
1000  times  that  of  wide  area  networks  (WAN) .  [Ref.  10] 

In  client/server  computing,  there  are  usually  multiple 
processors:  a  workstation  for  making  an  entry  and  then 
multiple  servers,  in  which  transactions  are  processed 
across  and  finally  several  databases  that  updated  to 
reflect  the  transaction.  There  is  typically  a  three-level 
hierarchy  of  servers.  The  first  level  is  the  workstation, 
the  middle  level  is  the  work  group  server,  and  the  highest 
level  is  the  enterprise  server.  A  two-level  hierarchy  can 
also  suffice  in  a  client/server  environment  in  which  the 
workstation  interacts  directly  with  the  enterprise  server 
or  mainframe . 
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E. 


NETCENTRIC/NETWORK-CENTRIC  COMPUTING 


The  promising  new  platform  for  the  first  decade  of  the 
new  millennium  seems  to  be  netcentric  or  network-centric 
computing.  Some  of  the  new  capabilities  that  promise  to 
revolutionize  computing  in  the  netcentric  environment  are 
the  use  of  browsers  to  create  universal  clients,  the 
establishment  of  direct  supplier-to-customer  relationships, 
the  ability  to  share  richer  documents  than  at  any  other 
time  in  history,  and  application  version  checking  and 
dynamic  update.  [Ref.  10] 

Netcentric  computing  is  a  natural  evolution  of 
client/server  technology  best  represented  by  a  mathematical 
formula,  Mark  Goodyear  [Ref.  10]  states  as, 

"Netcentric  =  Cl lent /Server  +  Reach  +  Content" 

This  formula  shows  netcentric  computing  as 
client/server  computing  with  the  new  and  improved 
capabilities  of  "reaching,  interacting,  communicating, 
transacting,  and  partnering  with  more  entities  in  more 
locations;  and  there  are  new  and  richer  forms  of  content 
being  published,  interacted  with,  or  transacted."  [Ref.  10] 


III. 


BACKGROUND 


A.  HISTORY 

The  Commandant  of  the  Marine  Corps  (CMC)  made  the 
decision  in  1997  to  cut  the  manning  level  of  the  Marine 
Corps'  administrative  occupational  specialty  by  over  1000 
billets.  The  decision  was  made  based  on  recommendations 
that  came  from  a  General  Officer' s  symposium  and  a  force 
structure  review  of  the  Marine  Corps.  [Ref.  1]  The 
recommendations  were  based  on  two  primary  facts  or 
statistics  that  came  from  the  review.  First,  most  combat 
units  were  being  staffed  under  targeted  goals  both  during 
deployments  and  especially  after  returning  from  scheduled 
six-month  deployments.  Additionally,  often  Marines  were 
being  recycled  from  units  returning  from  deployments  to 
units  going  out  on  deployment  or  being  sent  on  deployments 
with  other  units  ahead  of  their  deployment  schedule  in 
order  to  back  fill  vacant  billets.  The  second  factor  was 
the  size  of  the  Marine  Corps  administrative  community.  In 
1997  between  9,000  and  10,000  administrators  serviced 
approximately  175,000  Marines,  a  ratio  of  1:19,  whereas 
corporate  America's  average  ratio  was  1:68.  [Ref.  9] 

It  was  an  obvious  conclusion  that  there  must  be  some 
way  to  make  Marine  Corps  administration  more  efficient. 
However,  at  the  time  that  the  decision  was  made,  there  was 
no  clear-cut,  preplanned  vision  on  how  to  make  this  happen 
in  the  Marine  Corps  or  how  to  redistribute  the  workload 
within  the  now  smaller  administrative  community. 
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It  just  so  happened  that  the  right  technology  and  the 
right  technical  personnel,  along  with  the  oversight  boards 
setup  by  CMC  were  in  place  to  envision  the  TFAS . 

During  the  fall  of  1997,  I  Marine  Expeditionary 
Force  (MEF)  and  Marine  Forces  Reserve  (MarForRes) 
began  planning  to  test  the  concept  of 
consolidating  personnel  administration  services 
above  the  traditional  battalion/squadron  level. 

These  tests  were  developed  in  response  to  the  1997 
Force  Structure  Review  Groups  '  (FSRG) 
recommendations  to  seek  improved  methods  of 
performing  administration  while  reducing  the  size 
and  composition  of  the  01  occupational  field. 

These  tests  were  also  designed  to  exploit  the 
availability  of  improved  technologies  (tools, 
systems  and  solutions)  .  [Ref.  12] 

Additionally,  the  Marine  Corps  contracted  with  KPMG 
consulting  to  analyze  its  technical  architecture  and 
administrative  processes  to  determine  which  processes  would 
yield  the  most  savings  in  time,  manpower,  and  cost. 
Pricewat erhouseCoopers  was  hired  to  conduct  a  best  business 
practices  analysis  of  Marine  Corps  Personnel  Administration, 
an  analysis  of  corporate  better  business  practices  and 
finally  to  deliver  a  Personnel  Administration  alternatives 
and  cost-benefit  analysis  to  the  Corps  by  May  1999. 

The  backbone  of  the  Marine  Corps  administrative 
system  is  the  Marine  Corps  Total  Force  System  (MCTFS) .  The 
MCTFS  is  proprietary  back  office  mainframe  and  server 
technology  from  the  early  1980' s,  which  contains  integrated 
personnel  and  payroll  data  for  active,  reserve,  and  retired 
Marines . 

The  two  means  of  entering  or  retrieving  data  from  MCTFS 

are  the  On-Line  Diary  System  (OLDS)  and  the  Unit 

Diary/Marine  Integrated  Personnel  System  (UD/MIPS) .  While 
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these  systems  provide  commanders  and  personnel 
administrators  with  personnel  and  pay  data,  information  is 
not  readily  accessible  to  the  Marine.  This  system  relied 
heavily  upon  administrators  and  thus  creating  inefficiencies 
such  as  : 

•  Increased  processing  time  and  backlog 

•  Increased  data  entry  error  in  transferring 
information  from  paper-based  forms. 

•  Degraded  service  to  Marines  and  commanders. 

•  Increased  labor  costs  in  the  OlXX  (Admin) 
Occupation  Field  (OccFld)  because  of  the  need 
for  administrators  to  support  100  percent  of 
personnel  transactions.  [Ref.  9] 

The  implementation  of  the  MCTFS  predates  the  rapid 
growth  of  client/server  technology,  automated  workflow 
functionality  and  the  ubiquity  of  Web-based  applications. 
The  current  front-end  system  used  with  the  MCTFS  is  the 
UD/MIPS  that  is  based  on  batch  technology.  The  decision  to 
undertake  the  TFAS  initiative  provides  the  Marine  Corps  with 
significant  opportunities  to  automate  and  streamline  its 
personnel  administration  system.  The  TFAS,  as  discussed  in 
this  thesis  is  essentially  a  new  front-end  system  for  MCTFS. 
It  will  function  as  the  foundation  of  a  self-service  center, 
with  a  24-hour  call  center,  and  interactive  voice  response 
(IVR)  telephony  Web-based  applications.  [Ref.  9]  The  19 
business  processes  have  been  selected  for  reengineering  as 
part  of  the  new  streamlined  data  flow  process. 

Figure  7  below  is  a  diagram  of  the  current  environment. 
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Figure  7.  Current  Environment  From  Ref  [2] 

B.  CURRENT  SITUATION 

The  TEAS  is  still  in  phase  one,  which  is  scheduled  to 
last  through  fiscal  year  2002  (September  30,  2002)  . 
Administrative  Marines  have  already  been  consolidated  from 
the  battalion  and  squadron  level  to  the  regimental  and  group 
level.  [Ref.  13]  An  interim  set  of  standardized  tools  and 
processes  have  been  deployed  Corps  wide.  Other  things 
scheduled  for  completion  during  phase  one  are  the 
development  of  a  technology  acquisition  strategy  and 

establishment  of  Military  Construction  (MilCon) 
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requirements;  and  the  completion  of  the  technical 
architecture  plans  (scheduled  to  be  completed  by  end  of 
FYOO)  .  The  Marine  Corps  plans  to  use  an  Abbreviated 
Acquisition  Program  profile  to  acquire  the  TFAS .  The  TFAS 
is  currently  budgeted  at  $12.8  million  and  with  a  request 
for  $11.6  million  in  FY02.  [Ref.  1] 

The  TFAS  leadership  after  reviewing  the  options 
presented  by  the  PricewaterhouseCoopers  analysis  has  chosen 
alternative  one  as  the  best  option.  The  Marine  Corps  did 
not,  however,  contract  with  PeopleSoft  as  the  contractor  for 
the  project  as  the  analysis  recommended,  choosing  instead  to 
tackle  the  front-end  in  house. 

It  should  be  noted  that  alternative  two  was  the  option 
with  the  greatest  cost  to  benefit  ratio.  [Ref.  9]  However, 
each  of  the  options  was  less  expensive  than  the  status  quo, 
due  to  the  manpower  intensiveness  of  the  current  system. 


Alter¬ 

native 

Description 

One 

Maintain  the  MCTFS  and  implement  self-service 
technology.  This  alternative  includes  developing 
Web-based  applications  and  interactive  voice 
response  (IVR)  telephony  to  enable  individual 
Marines  to  conduct  routine  transactions  without 

assistance  from  an  administrator.  These  new 
applications  would  be  integrated  with  the 
existing  MCTFS.  This  alternative  also  includes 
developing  a  shared-service  call  center  for 
Marines  who  require  additional  assistance. 

Two 

Replace  MCTFS  with  a  Human  Resources  Information 
System  (HRIS)  and  implement  self-service 
technology.  This  alternative  includes  replacing 
MCTFS  with  a  COTS  client/server  HRIS.  Also,  it 
includes  developing  Web-based  applications  and 
IVR  telephony  to  enable  individual  Marines  to 
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conduct  routine  transactions  without  assistance 
from  an  administrator.  These  new  applications 
would  be  integrated  with  the  HRIS.  This 
alternative  also  includes  developing  a  shared- 
service  call  center  for  Marines  who  require 
additional  assistance. 

Three 

Maintain  MCTFS  and  outsource  the  management  of 
self-service  technology.  This  alternative 
involves  selecting  an  outsourcing  contractor  to 
provide  Web-based  applications  and  IVR  telephony 
to  enable  individual  Marines  to  conduct  routine 
transactions  without  assistance  from  an 
administrator.  The  contractor  would  provide  call 
center  services  for  Marines  who  require 
additional  assistance. 

Table  1.  Summary  of  Alternatives  From  Ref.  [9] 

The  Marine  Corps  has  invested  approximately  $1.1  million  in 

TFAS  over  the  past  two  fiscal  years. 

1 .  Marine  OnLine  (MOL) 

The  Marine  Corps  has  established  the  foundation 
of  a  Web-based  self-service  environment  through 
the  creation  of  Marine  on  Line  (MOL) .  The  MOL  is 
the  portal  or  communications  medium  that  will 
allow  Marines  regardless  of  location  to  access 
and  interface  electronically  with  their  personnel 
data  via  any  standard  web  browser  connected  to 
the  Internet.  The  MOL  has  been  designed  to 
employ  state-of-the-art  security  architecture  to 
include  Lightweight  Directory  Access  Protocol 
(LDAP)  and  Secure  Socket  Layer  (SSL) . 
Appropriate  technologies  such  as  Public  Key 
Infrastructure  (PKI)  combined  with  the  proper 
business  rules  will  authenticate  the  identity  of 
the  individual  submitting  information  for 
processing.  Verification  procedures  will  ensure 
the  validity  of  the  information  being  submitted. 

[Ref.  2] 


Information  from  Marine  service  records  have  already 
been  linked  to  the  MOL  Website  http://www.mol.usmc.mil/. 


30 


with  a  UserlD  and  password.  Marines  can  go  online  now  and 
view  or  query  selected  data  such  as  personal,  training,  and 
service  information  about  themselves  and  their  units.  The 
MOL  will  be  linked  to  the  DFAS  Employee/Member  Self-Service 
(E/MSS)  site  and  the  Marine  Corps  Operational  Data  Store- 
Enterprise  (ODSE) .  The  Marines  have  reengineered  processes 
in  19  areas  that  are  being  prepared  for  the  TEAS  and  the  MOL 
Website.  These  modules  are  being  tested  in  the  Eleet  Marine 
Force  (FMF)  and  will  be  implemented  in  modules  once  TFAS 
architecture  has  been  implemented  throughout  the  enterprise. 

It  should  be  stated  that  the  Marine  Corps  was  able  to 
start  the  TFAS  initiative  in  FYOO  because  of  its  cost  and 
schedule  strategy  which  will  allow  the  leveraging  of  current 
resources  allocated  to  UD/MIPS,  MCTFS,  and  TFAS.  [Ref.  2] 

2.  Information  Technology  Directorate,  Kansas  City 
Center  (IDT-KCC) 

The  TFAS  leaders  chose  ITD-KCC  as  the  integrator  for 
the  TFAS  project.  This  decision  was  made  based  on  ITD- 
KCC' s  familiarity  with  the  MCTFS  and  UD/MIPS  and  ITD-KCC' s 
established  service  record  of  meeting  the  demands  of  the 
Marine  Corps  pay  and  personnel  communities  while  providing 
cost  effective  service.  [Ref.  2]  The  ITD-KCC  was  once  a 
Marine  Corps  Central  Design  and  Programming  Activity.  The 
ITD-KCC  created  the  MCTFS  that  is  considered  the  only 
integrated  personnel  and  pay  system  within  the  DoD  and  one 
of  the  most  technologically  current  personnel  and  pay 
client-server  systems,  UD/MIPS,  found  in  the  DoD. 
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3. 


Software  Development 


The  TFAS  will  use  the  existing  configuration  control 
board  for  the  MCTFS  and  the  UD/MIPS  that  consists  of  ITD- 
KCC,  the  Marine  Corps  and  DFAS-KC.  Software  will  be 
released  during  the  normal  MCTFS  and  UD/MIPS  software 
release  schedule  of  April  and  October  of  each  year.  The  TFAS 
has  been  broken  down  into  19  separate  work  packages  that 
will  be  phased  in  by  fiscal  year.  Preliminary  documents  do 
not  specifically  say  who  will  create  the  software  for  the 
TFAS.  Regardless  of  who  creates  the  software,  there  are  two 
concepts  that  are  critical  to  interoperability  when  writing 
this  software. 

a.  Modularity 

Modularity  is  important  when  writing  software 
because  it  can  isolate  system  and  hardware  platform 
dependencies.  Modularity  allows  the  isolation  of 
operations  or  processes  that  are  likely  to  change, 
isolation  of  data  management,  and  the  isolation  of  input 
and  output,  which  is  what  the  TFAS  wants  to  change  most. 
Modularity  supports  encapsulation,  which  can  result  in 
greater  cohesiveness.  Cohesion  is  defined  here  by  how 
closely  the  operations  are  related  in  a  module  and  by  the 
functionality  of  the  unit.  The  best  cohesion  is  functional- 
each  module  or  unit  has  only  one  task.  [Ref.  14] 

b.  Loose  Coupling 

Highly  coupled  modules  traditionally  have  more 
errors  and  are  more  costly  to  maintain.  Therefore,  loose 
coupling  is  considered  the  best  practice.  "Good  coupling 
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between  units  is  loose  enough  that  one  unit  can  easily  be 
used  from  another."  [Ref.  14]  Coupling  refers  to  the 
strength  of  a  connection  between  two  modules  or  units  of 
connection . 

4 .  Risks 

Managers  for  the  TFAS  have  identified  the  risks 
associated  with  the  initiative  and  developed  a  risk 
mitigation  strategy.  Risks  identified  include  the 

following:  [Ref.  2] 

a.  Project  Risks 

•  TFAS  relationship  to  the  Defense  Integrated 
Military  Human  Resources  System  (DIHMRS) 

•  Available  funding  for  out  years 

•  Selection  of  a  vendor (s)  and 

•  Ability  to  execute  the  plan 

ib.  Technical  Risks 

•  Technical  architecture  design 

•  Infrastructure  support 

•  The  infusion  of  new  technology  into  the 
current  service  model 

c.  Development  Risks 

•  The  software  development  environment 

•  Integration  with  current  initiatives 
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Figure  8 .  Primary  Baseline  Technology  for  Personnel 
Administration  From  Ref.  [9] 


C.  DIFFERENCES  BETWEEN  THE  MILITARY  AND  CORPORATE  AMERICA 

There  are  differences  between  corporate  America  and 
the  military  that  can  effect  how  an  ERP  or  enterprise 
system  is  implemented.  It  is  important  to  highlight  these 
differences  prior  to  moving  to  the  analysis  portion  of  this 
thesis.  Figure  9  below  illustrates  that  the  information 
systems  direction  and  computing  architecture  for  an 
organization  is  derived  from  its  organizational  direction 
and  requirements. 
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■  Mission 

■  Strategic  Objectives 

■  Strategies 

■  Computing  Architecture 

■  Policies  and  Responsibilities 

■  Annual  Objectives 

■  Service  Architecture 

Figure  9.  Current  IS  Situation  Summary  From  Ref.  [15] 


It  is  very  obvious  that  the  military  has  a  different 
mission  and  strategic  objective  than  corporate  America. 
Corporations  are  in  the  business  of  making  money.  There 
interests  in  implementing  an  ERP,  e-business  or  enterprise 
information  systems,  will  be  centered  on  building  corporate 
wealth.  This  can  involve  increasing  consumer  satisfaction, 
consumer  loyalty,  and  giving  contractors  and  consumers 
outside  of  the  enterprise  access  to  information  found  in 
applications  and  databases.  The  military  does  not  sell  a 
commercial  product.  Our  customer  is  usually  someone  within 
the  enterprise. 

The  biggest  difference  between  the  military  and  most 
organizations  are  the  environment  and  external  requirements 
in  which  our  systems  must  be  able  to  operate.  Corporate 
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America  does  not  have  to  worry  about  a  potentially 


constantly  changing  hostile  environment,  such  as  a 
deployment  or  in  a  combat  zone  in  the  middle  of  the  desert. 
Our  garrison  architectures  often  look  alike  with  the 
exception  that  the  military  must  build  redundancy  into 
their  system  and  account  for  being  able  to  communicate  with 
minimum  bandwidth  in  situations  such  as  those  mentioned 
previously . 


Military  systems  often  have  long  acquisition  times  and 
cycles  because  of  the  Congressional  budget  and  oversight 
process.  The  military  often  does  not  use  cutting  edge 
technology.  In  the  information  systems  arena,  even  when 
the  military  attempts  to  use  cutting  edge  technology,  by 
the  time  the  project  has  been  completed,  the  technology  is 
no  longer  cutting  edge.  There  have  been  recent  exceptions 
to  this  rule  under  abbreviated  acquisition  rules.  The 
military  does  not  have  competitors  in  the  traditional  sense 
and  thus  has  more  of  a  focus  on  increased  efficiency  and 
quality. 

Both  military  and  corporate  organizations  share  the 
same  type  of  concerns  surrounding  sound  architectural  and 
project  implementations.  However,  corporations  normally 
try  to  implement  IT  changes  as  quickly  as  possible,  the 
military  normally  takes  a  slower,  deliberate  approach  to 
implementation.  The  biggest  reason  for  this  is  that  the 
corporation  normally  considers  opportunity  costs  as  a  part 
of  the  equation  when  determining  the  actual  implementation 
costs.  The  military  normally  wants  the  system  to  work  at 
the  end  of  the  implementation  on  or  near  budget.  Different 
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information,  external  and  business  requirements  lead  to 
different  implementation  times. 

There  are  different  security  considerations  between 
military  and  other  organizations.  Access  to  military 
systems  are  usually  concerned  with  allowing  access  only  to 
personnel  within  the  enterprise.  However,  most 
corporations  have  multi-tiered  relationships  with 
customers,  potential  customers,  contractors,  suppliers,  and 
employees  involving  international  and  multilingual 
requirements.  The  military  has  security  concerns  that 
will  require  stringent  user  identification  and 
authentication  prior  to  access  to  any  portion  of  the 
enterprise  system.  Thus  while  corporate  America  is  ensuring 
that  their  platforms  will  allow  for  the  connection  of  their 
systems  to  other  suppliers  and  customers,  the  military 
builds  their  systems  to  prevent  unauthorized  access  to 
their  systems.  This  difference  is  the  reason  that  military 
systems  must  use  modularity  and  loose  coupling  in  the 
majority  of  their  systems. 

The  military  lifecycle  for  systems  and  programs  is 
different  than  corporate  America.  Example,  when  corporate 
America  purchases  a  computer,  often  that  computer  will  be 
upgraded  or  replaced  in  18-month  cycles;  the  military  will 
keep  this  same  computer  in  its  inventory  for  many  years, 
sometimes  for  as  long  as  it  is  functional.  It  is,  however, 
more  risky  for  most  organizations  to  upgrade  their  software 
than  it  is  to  upgrade  their  hardware. 

According  to  PricewaterhouseCoopers ,  the  Marine  Corps 
personnel  administration  shares  similar  functions  with 
corporate  human  resource  systems  many  of  which  have  been 
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modernized  to  include  a  self-service  capability.  [Ref.  9] 
This  suggests  that  a  self-service  capability  for  the  Marine 
Corps  personnel  administration  is  a  natural  evolution.  The 
differences  between  the  two  are  the  processes  and 
environmental  factors  previously  mentioned. 
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IV.  LESSONS  LEARNED  FROM  CORPORATE  ERP 


IMPLEMENTATIONS 


The  information  gathered  and  compiled  for  this  chapter 
comes  from  books,  case  studies,  and  magazine  articles 
related  to  e-business,  e-commerce,  supply-chain  management, 
ERP,  and  other  enterprise  information  system 
implementations  over  the  past  couple  of  years.  I  attempted 
to  capture  the  mistakes,  problems,  successful  strategies, 
and  hints  that  recurred  most  in  my  research  or  that  stood 
out  as  being  relevant  to  the  TEAS.  Keeping  in  mind  the 
differences  between  corporate  America  and  the  military  that 
were  stated  previously,  the  lessons  learned  that  appear  in 
the  body  of  this  chapter  will  not  all  apply  to  the  TEAS 
implementation.  Einally,  I  will  focus  on  compiling  a  list 
of  Key  Success  Eactors  for  the  TEAS  implementation. 

It  should  be  noted  that  ERP  projects  outside  of  the 
military  have  a  reputation  for  running  over  cost  and  behind 
schedule.  However,  there  are  numerous  examples  over  the 
past  two  years  of  ERP  implementations  that  have  been  both 
within  cost  and  schedule.  Web  or  Internet  based 
implementations  have  become  extremely  popular  during  this 
time  . 


A.  COMMON  MISTAKES 

The  most  common  mistakes  that  ERP  vendors,  major 
corporations,  and  other  organizations  have  reported  from 
enterprise-wide  information  system  implementations  follow. 
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These  mistakes  are  not  listed  in  order  of  importance  or 
frequency  of  occurrence. 


Companies  often  choose  ERP  packages  simply  from 
the  functional  requirements  of  the  business 
without  considering  the  company' s  ability  to 
migrate  to  the  package.  [Ref.  10] 

Most  systems  focus  primarily  on  either  the 
planning  requirements  (on  the  front  end)  or  the 
time  and  attendance/data  collection  (on  the  back 
end) .  [ Ref .  6 ] 

An  organization  does  not  know  its  own  system. 
Integration  of  existing  systems  is  a  regular 
speed  bump  of  ERP  implementations.  "There  are 
often  surprises  lurking  in  legacy  systems  and 
processes"  says  James  McCullough  a  former  CIO 
with  Delta  Airlines  [Ref.  16]  McCullough  says  of 
an  ERP  implementation  "We  thought  we  understood 
how  the  previous  system  worked...but  when  we  really 
got  down  to  it,  we  found  it  wasn't  like  we 
thought .  " 

Organizations  attempt  to  customize  packages. 
Customizing  packages  should  be  a  last  resort  in 
rapid-implementation  plans,  as  the  practices 
included  in  these  plans  are  usually  better  than 
existing  practices.  However,  in  the  military  we 
often  get  locked  into  processes  that  we  would 
like  to  change  due  to  Eederal  laws  and 
regulation.  [Ref.  17] 

Assumption  that  careful  planning  will  lead  to 
success.  It  takes  vigilant  monitoring  of 
detailed  goals,  the  committed  involvement  of 
executives  and  workers  alike,  a  focus  on  customer 
needs  and  the  careful  building  of  a  business  case 
for  the  endeavor.  [Ref.  17] 

The  organization  identified  the  new  or 
destination  architecture  too  late.  Architecture 
in  this  passage  refers  to  designing  the  system 
prior  to  determining  the  business  direction  or 
interrelationship  and  processes  that  must  occur. 
[Ref.  10] 
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The  information  from  the  back  end  of  ERP  does  not 
always  make  it  into  e-commerce  (Web-based 
portals,  front-end  system)  applications.  [Ref. 
18] 


Difficulties  with  defining  uniform  data  fields 
and  ensuring  data  integrity.  The  result  is  IT 
departments  can  not  accurately  track  their  e- 
commerce  data  in  their  ERP  systems  and  can  not 
push  information  from  ERP  to  e-commerce 
applications.  [Ref.  19] 

Implementation  takes  longer  than  planned.  The 
average  ERP  implementation  takes  between  one  to 
three  years.  "Real  transformational  ERP  efforts 
usually  run  between  one  to  three  years,  on 
average."  [Ref.  20]  Do  not  focus  on  how  long  it 
takes  to  implement  the  program;  rather  focus  on 
why  you  need  it  and  how  you  will  use  it  to 
improve  your  business.  Note:  ERP 
implementations  have  gotten  quicker.  This  comes 
from  a  1999  case  study. 

ERP  has  hidden  costs  that  can  result  in  budget 
overrun.  [Ref.  20]  Training,  integration  and 
testing,  data  conversion,  data  analysis,  and 
post-ERP  depression  are  just  some  of  the  hurdles 
that  must  be  jumped  in  an  ERP  implementation. 
Acquisition  overruns  are  still  common  in  ERP 
implementations  today.  However,  underestimate 
the  cost  to  upgrade  the  IT  infrastructure  support 
is  an  overrun  that  is  common  but  less  publicized. 


Planners  do  not  allot  enough  time  in  the  work 
plan  to  deal  with  vendor  problems.  [Ref.  6] 


Most  enterprises  end  up  with  incompatible 
technical  architectures.  Two  most  contributing 
factors  to  this  are:  1)  Bad  decisions  on  how  to 
handle  legacy  systems  and  2)  IS  personnel  take 
too  long  to  come  up  with  a  decision  about 
technical  architecture  and  then  the  end-user 
community  goes  ahead  without  the  Information 
Systems  department  involvement.  [Ref.  10] 


Companies  do  not  budget  or  plan  for  the  costs  of 
new  IT  skills  and  infrastructure  in  addition  to 
the  ERP  package  implementation.  The  technical 
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audit  helps  indicate  the  cost  of  migrating  to  ERP 
packages.  [Ref.  17] 

•  Most  companies  do  not  have  good  change  management 
resources.  [Ref.  17] 

B.  KEY  SUCCESS  FACTORS 

The  factors  below  were  recurring  themes  in  my 
literature  review.  If  you  put  a  "did  not"  in  front  of  the 
following  key  success  factors,  the  result  would  be 
additional  things  that  could  be  added  to  the  list  of 
mistakes  an  organization  can  make  during  an  ERP 
implementation.  The  things  that  should  be  done  are  as 
follow : 

•  Plan  prior  to  implementation.  Plan  for  actual 
rollout  of  the  new  system  early  on  in  the  project 
cycle.  Perform  an  IT  readiness  assessment  to 
determine  if  the  necessary  IT  infrastructure  is 
in  place  to  make  sure  each  site  can  handle  the 
new  system.  [Ref.  21] 

•  Users  should  conduct  a  rigorous  internal  audit 
before  selecting  application  packages  to  ensure 
package-readiness  and  to  facilitate  the  package 
selection  and  implementation  process.  [Ref.  22] 

•  The  various  architectures  must  be  established  and 
agreed-upon  prior  to  starting  work  on  the  first 
application.  All  system  developers  should  employ 
this  architecture  as  a  framework  for  their  design 
efforts.  [Ref.  10] 

•  The  organization  must  conduct  a  thorough  review 

of  business  and  technical  audit  prior  to 

selecting  the  ERP  package.  The  package  you 

choose  should  be  based  on  business  goals  rather 
than  desirability  of  features.  [Ref.  10] 

•  Perform  a  Legacy  Audit  where  the  existing 
applications  are  divided  into  three  categories. 
1)  Maintain,  2)  Maintain  and  interoperate,  or  3) 
Replace  with  new  solutions.  [Ref.  2] 
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Companies  need  to  consider  the  practicality  (cost 
and  complexity)  of  their  real-time  requirements. 
Companies  need  to  decide  whether  to  focus  on  a 
unified  mega-center  approach  or  on  distributed 
islands  of  automation.  [Ref.  22] 

An  ERP  package  should  be  viewed  as  a  framework 
capable  of  supporting  targeted  niche  solutions. 
The  corporate  project  team  should  determine  the 
required  integration  for  each  division  and 
evaluate  existing  working  solutions  as  well  as 
targeted  niche  alternatives.  [Ref.  22] 

Form  an  effective  project  team  and  establish 
effective  communication  mechanisms  up,  down,  and 
across  the  organization.  [Ref.  22] 

The  project  team  must  have  representation  from 
senior  management,  application  package  vendor, 
the  systems  integrator,  the  database  vendor,  and 
the  hardware / server  vendor.  [Ref.  22] 

A  system  integrator  should  be  used  for  large  ERP 
projects.  [Ref.  16] 

Consider  the  presentation  tier,  application  tier, 
and  database  tier  when  designing  the  architecture 
of  ERP  packages.  The  separation  of  the 
presentation,  application,  and  data  layers 
(either  physically  or  logically)  has  become  the 
accepted  paradigm  for  building  deliverable, 
modular,  and  updateable  client/server 
applications.  Good  application  design,  with 
emphasis  on  reducing  network  input/output  is 
critical  to  success  in  client/server 
environments.  Additionally,  selecting  scalable 
and  high-performance  servers  and  tuning  them 
properly  is  also  essential.  [Ref.  22] 

Users  should  choose  infrastructure  components 
(hardware,  DBMS,  operating  system)  with  the 
broadest  market  acceptance.  They  will  have  the 
broadest  potential  "integration  tool  set"  from 
which  to  choose.  [Ref.  23] 

Users  should  attempt  to  run  all  operational 
applications  against  a  single  operational  data 
store  because  this  provides  for  the  best  or  most 
elegant  integration.  If  this  is  not  possible  the 
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user  should  focus  on  the  openness  of  the 
applications  data  model  and  the  underlying 
infrastructure  platform.  [Ref.  22] 

Ensure  extensibility  of  the  system.  [Ref.  22] 

Users  should  anticipate  the  need  to  extend  ERR 
packages  to  data  warehouses  and  pay  particular 
attention  to  the  infrastructure  requirements. 
[Ref.  12] 

Develop  a  quantifiable  business  case.  Establish 
concrete  goals  for  the  business  processes  you 
want  to  improve  and  calculate  the  expected 
benefits  to  be  realized  from  these  improvements. 
[Ref.  20] 

Define  best  practices.  Identify  key  migration 
points  and  the  precise  type  and  timing  of  change. 
[Ref.  21] 

Strictly  monitor  implementation  schedules  and 
costs.  Once  rollout  actually  begins,  all 
milestones  should  be  carefully  tracked,  measured 
and  rechecked  to  ensure  that  scheduled  changes 
were  made  on  time  and  on  budget.  [Ref.  21] 

Cross-cultural  training.  Make  sure  that  all 
affected  people  are  provided  with  training  on  the 
new  program.  [Ref.  21] 

Rigorous  tracking  of  deliverables.  Identifying 
and  then  relentlessly  tracking  the  complex  web  of 
incremental  milestones  is  critical  to  the  success 
of  a  project.  [Ref.  21] 

Access  to  all  tools  should  be  accessed  from  one 
portal.  Portals  can  be  customized  based  on  the 
level  of  user  or  all  users  can  see  the  same  menus 
but  with  access  safeguards  built-in.  A  single 
access  point  can  also  be  a  security  feature. 
[Ref.  24] 

Map  out  the  functions  that  an  integrated  system 
must  perform.  [Ref. 17] 

Articulate  expectations  before  implementation. 
What  will  the  project's  stakeholders  say  are  the 
attributes  of  the  new  environment  in  a  year? 
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Where  are  the  gaps  in  the  plan?  What  conflicts 
of  opinion  exist  today?  [Ref.  17] 

Do  not  change  too  much  at  once.  Major  change 
requires  an  evolutionary  approach.  Do  not 
overwhelm  your  organization  with  a  system  that 
has  more  functionality  than  you  absolutely  need. 
Consider  a  phased  rollout  and  shoot  for  short 
wins  to  generate  momentum  during  the  project. 
[Ref.  17] 

Keep  to  the  basics.  Resist  customizing  the 
software  or  including  optional  features  ...  ways 
aim  high  enough  to  make  a  difference,  but  not  so 
high  that  the  target  will  be  missed, "  says  Jorge 
Taborga,  vice  president  and  CIO  of  Bay  Networks 
Inc.  [Ref.  17] 

Do  not  let  technical  problems  dominate  the 
project's  time.  Create  a  dedicated  staff 
position  for  change  management  within  the 
organization.  Use  your  best  and  brightest  people 
on  the  change  team.  [Ref.  17] 

View  ERR  implementation  as  a  business  initiative, 
not  an  IS  initiative.  [Ref.  18] 

Keeping  an  integration  project  in-house  can  offer 
the  freedom  to  find  creative  solutions  to 
integration  problems.  Hacking  through  an 
integration  process  in-house  lets  CIOs  experiment 
with  various  integration  methods  and 
architectures."  [Ref.  18] 

Do  not  be  afraid  to  hire  out.  [Ref.  18] 

ERR  implementations  often  leave  the  company  still 
in  a  position  where  it  cannot  share  information 
horizontally.  These  companies  have  to  figure  out 
how  to  connect  their  internal  e-commerce  and  ERR 
applications  outside  of  the  enterprise.  In  the 
military,  we  would  be  concerned  about  possibly 
being  able  to  share  information  in  a  joint 
environment.  [Ref.  18] 
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Figure  10  below  is  a  summary  of  the  key  success 


factors  for  any  enterprise  information  system 
implementation . 


ERP  Key  Success  Factors 

■  Conduct  a  rigorous  Internal  audit  before  selecting 
a^lication  packages  to  ensure  "package -readiness"  and  to 
facilitate  the  package  selection  and  in^lenentation. 

•  Establish  architectures  prior  to  starting  inirk  on  the 
first  application.  This  architecture  should  be  franeiiork 
for  all  design  efforts. 

■  Budget/plan  for  the  costs  of  new  IT  skills  and 
infrastructure  in  addition  to  the  ERP  package 
inplement atio n . 

■  Create  an  effective  project  team  with  representation  from 
staiceholders  across  the  organization. 

•  Establish  effective  coiranunication  mechanisms  down, 

and  across  the  organization. 

■  Choose  infrastructure  components  (hardware,  DBKS, 
operating  s^tem)  with  the  broadest  market 
acceptance. this  facilitates  easier  integration  later. 

■  Consider  the  presentation  tier,  application  tier,  and 
database  tier  \dien  designing  the  architecture  of  EKP 
packages . 

■  Attempt  to  run  all  operational  applications  against  a 
single  operational  data  store.  If  this  isn't  possible, 
focus  on  the  openness  of  the  applications  data  model  and 
the  underlying  infrastructural  platform. 

■  Anticipate  the  need  to  extend  ERP  packages  to  data 
warehouses  and  pay  particular  attention  to  the 
infrastructure  reguirements. 

■  Strictly  monitor  inplementation  schedules  and  costs. 

■  Hap  out  the  functions  that  an  integrated  system  must 
perform. 

■  Articulate  expectations  before  implementation. 

■  Don't  change  too  much  at  once . 

■  Don't  let  technical  problems  dominate  the  project's  time. 
Create  a  team  to  trouble-shoot  problems. 

■  Don't  be  afraid  to  hire  out. 

■  Resist  customizing  the  software  or  including  optional 
features. in  other  words  stick  to  the  basics. 


Figure  10.  Traditional  ERP  Key  Success  Factors 
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Figure  11  below  is  a  condensed  list  of  the  things  that 


I  consider  the  most  relevant  to  the  TFAS  project. 


Consider  ttie  presentation  tier,  application  tier,  and 
database  tier  when  designing  the  architecture.  This 
involves  not  only  separate  servers  for  the  different 
tiers  but  also  modularizing  software  by  function  for 
each  tier  additionally. 

Establish  architectures  prior  to  starting  work  on  the 
first  application.  This  architecture  should  be 
framework  for  all  design  efforts.  (Appears  fron 
documentation  as  if  this  could  have  alreac^  occurred. 
Beware  of  possible  conseguences . ) 

Choose  infrastructure  components  (haribrare,  DEIIS , 
operating  system)  with  the  broadest  market 
acceptance. this  facilitates  easier  integration  later. 
Additionally,  the  more  coiimon  the  components,  the 
easier  it  will  be  to  get  support  from  the 
manufacturer... especially  5  years  down  the  road. 

Beware  that  integration  of  existing  systems  could  be 
the  biggest  hurdle  to  this  implementation.  This  is 
less  of  a  concern  with  the  TFAS  but  more  of  concern 
with  the  DIHRMS .  Will  the  TFAS  architecture  be 
compatible  with  PeopleSoftB  software? 

Beware  that  in  Corporate  ERP  implonentations , 
information  from  the  back  end  of  ERF  doesn't  always 
make  it  into  the  front  end  systems.  This  would  be 
catastrophic  for  the  TFAS  initiative;  test  early  and 
often . 


Figure  11.  TFAS  Key  Success  Factors 
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The  lessons  listed  while  seeming  universal  are  not 
applicable  to  all  enterprise  system  implementations.  The 
mistakes  and  success  factors  are  not  all  applicable  to 
military  enterprise  systems.  They  are  not  even  universal  to 
all  corporate  enterprise  implementations.  It  should  be 
noted  that  this  list  is  not  all-inclusive.  Absent  from 
most  of  the  literature  I  reviewed  were  concerns  for 
building  operational  type  security  features  into  the 
enterprise  system.  Additionally,  there  was  little  in  the 
lists  on  communication  platform  mistakes.  The  unique 
requirements  of  military  systems  and  the  environments  in 
which  our  systems  must  work  in  are  part  of  the  reason  for 
this.  I  am  sure  that  there  are  other  areas  that  I  have  not 
covered  in  this  thesis.  Thus,  those  who  know  the  TFAS 
system  the  best  must  add  to  this  list  of  key  success 
factors . 
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V. 


EVALUATION  OF  TFAS' ARCHITECTURE 


Mark  Goodyear  [Ref.  10],  states  that  the  four  main 
components  of  effective  enterprise  information  architecture 
are  the  business  solutions,  application  architecture, 
technical  architecture,  and  the  communications  platform. 
This  thesis  only  attempts  to  evaluate  the  technical 
architecture  of  the  TFAS  initiative. 

The  business  solution  architecture  is  a  combination  of 
the  environment,  business  requirements  and  data 
architecture.  Goodyear  says,  "When  it  comes  time  to  decide 
what  technical  architecture  to  use,  many  of  the  answers  are 
found  by  looking  at  the  business  solutions  architecture." 
[Ref.  10]  The  applications  architecture  refers  to  those 
components  that  provide  the  automation  support  for  a 
business  function  or  activity  not  including  the  platform. 
The  technical  layer  is  comprised  of  the  (1)  execution 
architecture,  (2)  development  architecture,  (3)  operations 
architectures,  and  (4)  the  infrastructure  and  system 
software  layers  combined.  The  platform  architecture 
involves  the  "servers,  workstations,  operating  systems,  and 
networks."  [Ref.  10]  Figure  12  is  an  illustration  of  how 
these  different  architectures  of  the  technical  layer  relate 
to  each  other  and,  as  a  whole  is  the  foundation  of  the 
enterprise  application. 

The  C4ISR  Architecture  Framework  states  that  the  three 
types  of  architectures  as  operational,  systems,  and 
technical.  "The  C4ISR  Architecture  Framework  provides 
guidance  on  describing  architectures."  [Ref.  5]  The  C4ISR 
puts  much  focus  on  architecture  views  or  diagrams  and  the 
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tools  available  to  build  effective  diagrams.  Chapter  III 
even  lists  six  steps  to  building  architecture.  However, 
reference  ten,  "Enterprise  System  Architectures:  Building 
Client/server  and  Web-based  Systems"  was  used  as  the  basis 
of  most  of  the  definitions  in  this  thesis  because  of  this 
thesis'  focus  on  corporate  and  enterprise  architecture. 


Figure  12.  Relationship  Among  the  Technical  Architectures 

From  Ref.  [10] 

A.  TECHNICAL  ARCHITECTURE 

1 .  No  Development  Architecture 

No  development  architecture  was  included  in  any  of  the 
preliminary  documents  or  in  the  study  conducted  by  the  two 
consultants  KPMG  and  Pr icewaterhouseCoopers  .  A  formal 
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technical  architecture  study  was  completed  and  published  by 
KPMG  prior  to  September  31,  2000  (FY'  00) .  However,  this 
study  has  not  been  posted  for  public  viewing  and  was  not 
provided,  as  requested  prior  to  the  completion  of  this 
thesis.  Therefore,  this  thesis  can  only  evaluate  the 
currently  published  architectural  information.  I  am  unaware 
of  whether  development  architecture  was  included  in  this 
technical  study.  The  TFAS  documentation  does  mention  that 
the  TFAS  will  be  accomplished  within  the  TAFIM  and  JTA 
architectural  standards.  Figure  13  and  figure  14  below  are 
the  JTA  and  TAFIM  models  that  TFAS  has  to  comply  with. 
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Figure  14.  TAFIM  Model  From  Ref.  [26] 
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However,  I  am  not  thoroughly  familiar  with  these  two 
models,  thus  this  thesis  will  not  evaluate  the  TAFIM  and 
JTA  models  and  how  they  apply  to  the  TFAS .  The  TFAS 
designers  have  listed  the  following  qualities  [Ref.  2]  that 
the  TFAS  architecture  will  have  to  take  into  consideration 
to  meet  TAFIM  and  JTA  standards. 

•  Interoperable  -  allowing  connectivity  and 
interchange  of  information  among  information 
resources  on  the  network,  application, 
presentation  and  data  levels  without  special 
connections,  procedures  or  other  intermediate 
translation,  and  gateway  devices. 

•  Transparent  -  providing  the  user  with  a  virtual 
information  services  environment  so  the  user  does 
not  need  to  know  where  the  applications  and  data 
reside . 

•  Scaleable  -  supporting  information  system 

environments  from  large,  fixed  facilities,  and 
networks  to  hand-held  and  disconnected  devices  in 
any  clime  or  place. 

•  Responsive  -  guaranteeing  assured  services, 

quickly  available,  when  and  where  needed 
worldwide . 

•  Secure  -  implementing  multiple  security  policies 
and  assuring  required  information  systems  and 
communications  security  and  availability. 

•  Easy  to  use  -  providing  intuitive  interfaces 

tailored  to  the  user's  preferences  where 
possible . 

•  Flexible  and  maintainable  -  architecture  must 

allow  quick  migration  and  integration  of  new 
applications  and  technology  (e.g.,  through  the 
use  of  standards-based  and  vendor-independent 
approaches) . 
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Reliable  -  architecture  must  support  alternative 
resource  and  service  access  or  graceful 
degradation . 


Affordable 
value  for 
services ) 
consistent 


-  architecture  must  provide  the  best 
required  services  (and  only  required 
in  the  most  efficient  way  available 
with  mission  needs. 


Evol vable 
methods , 
evolve  to 


architecture  must 
metrics,  tools,  and 
new  capabilities. 


include  special 
environments  to 


Survivable  - 

information 

requirements 


Architecture  must  ensure  essential 
is  available  to  meet  mission 
under  varying  conditions. 


Although,  not  included  in  this  list,  information 
integrity  and  operational  security  are  two  qualities  that 
all  military  system  architecture  should  have  as 
cornerstones  in  addition  to  the  list  above. 


Figure  15  is  a  guide  for  understanding  the  development 
architecture  or  environment  and  an  illustration  of  things 
that  should  be  included. 
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Figure  15.  Development  Architecture  From  Ref.  [10] 
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Mark  Goodyear  [Ref.  10]  raises  one  major  concern  about 
the  development  architecture  and  environment.  He  states  as 
follows : 

In  the  client/server  and  netcentric  environment 
it  is  vital  to  get  the  development  environment 
right  the  first  time.  Changing  the  development 
environment  when  construction  is  fully  staffed 
may  entail  serious  disruptions  and  expensive  loss 
of  productivity.  The  purpose  of  the  development 
architecture  is  to  support  the  tasks  involved  in 
the  analysis,  design,  construction,  and 
maintenance  of  business  systems  as  the  associated 
management  processes.  [Ref.  1] 

The  purpose  of  the  system  architecture  process  is 
to  provide  integral  technical  overview  and 
consistency,  to  maintain  the  integrity  over  time, 
and  bridge  the  gap  between  the  policy  and 
planning  process  and  the  product  creation 
process.  [Ref.  16]  The  technical  architecture 
provides  a  standard  and  consistent  approach  for 
creating  or  modifying  a  system.  Normally  a 
technical  architecture  will  have  three  parts: 
the  execution  architecture,  the  development 
architecture,  and  the  operations  architecture. 
Having  these  three  architectures  as  part  of  the 
overall  technical  architecture  provides:  "a 

common  background  for  information  system 
personnel,  a  more  rapid  delivery  solution  and  a 
reduced  impact  of  change.  [Ref.  10]" 

Muller  [Ref.  27]  indicates  that  the  key  issues  in 
ing  systems  architecture  plans  are:  balance, 

stency,  integrity,  simplicity,  and  elegance.  The 
to  be  balanced  by  the  system  architecture  process 
external  and  internal  requirements,  short  term  needs 
long  term  interests,  efforts  and  risks  from 


draft 
cons  i 
goals 
are  : 
and 
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requirements  to  verification,  detailed  designs  mutually, 
and  value  and  costs. 

Figure  16  demonstrates  that  as  project  complexity  and 
degree  of  business  process  increases  so  does  project  risk 
and  cost . 


Zone  1  Zone  2  Zone  3 


Figure  16.  Complexity  Increases  with  Increased  Process 

Change  From  Ref.  [6] 

Prior  to  implementing  any  system,  an  organization 
should  assess  its  current  capabilities  and  its  desired 
capabilities.  Figure  17  was  created  by 

Pricewat erhouseCoopers  [Ref.  6]  to  assist  companies  in 
determining  where  they  are  in  standard  enterprise  and  e- 
commerce  terms  and  where  their  desired  changes  will  take 
them.  Using  this  model  as  a  basis,  I  would  rate  the 
Marine  Corps'  current  system  as  a  borderline  Nonintegrated 
System  and  Limited/Single  Function  ERP  .  The  TFAS 

implementation  is  only  a  channel  enhancement  that  better 
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positions  the  Marine  Corps  to  move  to  the  value-chain 
integration  arena.  The  Marine  Corps  current  status  can  be 
seen  in  Figure  18.  It  is  highly  unlikely  that  the  DoD  or 
the  Marine  Corps  will  ever  achieve  or  even  desires  to 
achieve  the  industry  transformation  phase.  However,  the 
idea  of  achieving  an  integrated  Enterprise  ERP  system  is 
something  that  should  appeal  to  the  U.  S.  Marine  Corps  and 
the  other  military  services.  An  integrated  Enterprise  ERP 
system  is  one  in  which  human  resources,  finance,  supply  and 
logistics,  and  other  areas  such  as  recruiting  are  all 
interoperable  and  connected  allowing  for  richer  knowledge 
and  decision  support.  If  this  phase  could  ever  be 
achieved,  the  idea  of  convergence  would  then  be  imaginable, 
where  all  the  services  integrated  ERP  systems  could  be 
linked  together  for  the  sharing  of  information  within  DoD 
and  amongst  contractors. 


No  E'Business  Channel  Value-Chain  Industry  Convergence 

Capabilities  Enhancement  Integration  Transformation 


Eigure  17.  ERP  evolution  Erom  Ref  [6] 
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Figure  18.  The  TFAS  Evolution  After  Ref.  [6] 


B .  OPERATIONAL  ARCHITECTURE 

"The  operations  architecture  is  a  combination  of 
tools,  support  services,  procedures,  and  controls  required 
to  keep  a  production  system  up  and  running  well."  [Ref. 10] 
The  primary  users  of  the  operations  architecture  are 
"system  administrators  and  production  support  personnel." 
[Ref.  10] 

Figures  19  and  20  below  are  listed  in  the  TFAS 
documentation  as  operational  architecture  diagrams.  They 
actually  represent  more  of  a  data  flow  rather  than 
operational  architecture.  However,  since  these  are  the 
only  "operational  architecture"  diagrams  found  in  the 
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preliminary  assessment,  we  will  evaluate  the  information  in 
these  diagrams  at  this  time. 

1 .  Current  Operational  Architecture 

a.  Observations  from  the  "As— IS"  Operational 
Architecture 

The  "As-Is"  Operational  architecture  tells  the 
same  story  as  the  situational  state  diagram.  This 
architecture  shows  interaction  with  the  system  to  be 
limited  to  just  two  levels  in  the  current  architecture.  It 
demonstrates  the  systems  reliance  on  administrators  to 
validate,  authenticate,  enter,  and  access  data. 


Collect/Prepare/Approve 


Figure  19.  "As  Is"  Operational  Architecture  From  Ref.  [2] 
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2  .  Proposed  Operational  Architecture 

a.  Observations  from  the  "To-Be"  Operational 
Architecture 

The  "To-Be  architecture  is  simply  a  demonstration 
of  the  five  levels  of  interaction  with  the  current  system. 
The  purpose  of  the  TFAS  is  to  spread  the  responsibility  for 
keeping  records  up-to-date  from  the  administrator  to  the 
individual  Marine  and  others  in  the  chain-of -command .  The 
operational  architecture  accurately  portrays  this  concept. 
The  approval  blocks  show  some  of  the  controls  that  will 
disperse  throughout  the  system  at  different  levels. 


Figure  20.  "To  Be"  Operational  Architecture  From  Ref.  [2] 
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C .  EXECUTION  ARCHITECTURE 

The  Marine  Corps  describes  the  current  environment. 
Figure  21,  as  a  "state  of  the  art,  distributed  client- 
server  system"  that  has  evolved  in  the  last  three  years 
through  technology  refreshments."  [Ref.  2]  It  is  true  that 
the  current  architecture  has  client/server  capabilities. 
However,  the  majority  of  data  input  into  the  system  is 
still  based  on  batch  unit  diaries.  Information  can  be 
retrieved  via  UD/MIPS  online,  but  that  data  is  not  always 
the  most  current  due  to  the  processing  time  of  unit 
diaries.  The  TFAS  documentation  says  that  the  current 
system  is  "providing  users  access  to  information, 
resources,  and  capabilities  never  experienced  within  the 
realm  of  Marine  personnel  and  pay  administration."  [Ref.  2] 
While  this  may  be  true,  the  output  from  UD/MIPS  probably 
falls  somewhere  between  the  data  and  knowledge  realm.  It 
has  been  two  years  since  I  last  used  UD/MIPS  and  therefore 
am  unaware  of  whether  it  has  been  updated  to  provide  richer 
data  that  could  better  support  decision  support. 

The  TFAS  is  intended  as  mainly  a  garrison  solution  for 
Marines,  and  the  execution  diagrams  below  reflect  that 
view.  However,  for  the  TFAS  to  achieve  the  goal  of  being 
compatible  with  Operational  Maneuver  from  the  Sea  and  have 
the  reach  back  capability  that  this  will  require  deserves 
attention  now  in  the  early  stages  of  the  program.  With  the 
bandwidth  requirements  of  the  TFAS,  it  is  certain  that 
solutions  for  the  deployed,  bandwidth-limited  environment 
must  be  developed  to  allow  the  smallest  administrative 
footprint  possible.  Administrators  can  use  UD/MIPS  in  a 
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deployed  environment  much  as  they  do  today  to  handle  the 
bulk  of  the  administrative  workload.  However,  Marines  will 
be  used  to  having  information  at  their  fingertips  in 
garrison  and  would  have  to  adjust  their  routine  or  process 
for  handling  administration  while  embarked  on  ship  for 
example.  However,  options  can  be  built  into  the  system  to 
make  the  transition  from  garrison  to  austere  conditions 
easier  for  the  individual  Marine.  Some  of  those  options 
include  decoupling  the  information  system  to  facilitate  e- 
mail  transactions  to  the  PAG  rather  than  the  keystroke-by- 
keystroke  environment  they  would  encounter  via  the  Web;  A 
cd-rom(s)  with  all  Marine  info  could  be  deployed  with  the 
Marines  to  allow  Marines  to  continue  to  access  their  info 
per  the  latest  cd-rom  update;  or  using  secondary  memory 
(cache)  on  shipboard  servers  or  other  computers  to  store 
data.  Any  of  these  solutions  would  minimize  required 
bandwidth  and  interactivity  with  MCTFS  servers /databases 
and  PACs .  Additionally,  the  use  of  multi-casting  data  to 
the  PACS  could  reduce  PAC  interactivity  with  MCTFS  servers 
and  databases. 
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1. 


Level  1 :  The  Individual  Marine 


a.  Desired  End  State 

Capabilities  will  be  made  available  to  individual 
Marines  that  allow  them  to  submit  pay  and  personnel-related 
information  via  telecommunications  systems  to  central 
processing  activities,  identified  as  Personnel 
Administration  Centers  (PACs) .  Marines  will  primarily 
submit  transactions  via  a  Web-based,  menu-driven 
application  from  a  computer  with  Internet  access.  They 
will  be  able  to  access  their  pay  and  personnel  accounts  to 
review  information  and  to  submit  required  changes 
electronically,  telephonically  or  via  the  mail  without 
having  to  physically  go  to  a  personnel  administration 
office.  This  capability  will  also  be  available  from  ships 
and  the  full  range  of  expeditionary  environments.  [Ref.  2] 

b.  Figure  Depiction 

The  individual  Marine  will  be  able  to  access 
information  and  report  certain  transactions  via  a  computer 
with  a  Web  browser.  The  Marine  can  also  phone  the  Call 
Center  and  review  information  or  submit  transactions 
through  the  interactive  voice  response  system  (IVRS) .  In 
the  event  Marines  need  assistance,  they  will  be  able  to 
talk  directly  to  a  call  center  representative  who  will  them 
information  and  submit  certain  transactions  on  their 
behalf.  Marines  will  also  be  able  to  get  support  in  a 
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conventional  manner  through  their  small 
traditional  reporting  unit  admin  section. 


unit 


leader  or 


[Ref.  2] 


Figure  22.  Individual  Marine  From  Ref.  [2] 

c.  Analysis 

Success  of  the  TFAS  project  depends  upon  success 
at  this  the  first  level.  If  the  TFAS  implementation  works 

as  pictured  in  this  Figure  22,  which  shows  the  individual 

65 


of  the 


majority  of  his 


own 


Marine  taking  care 
administrative  needs  with  minimal  guidance  from  his  small 
unit  leadership.  Information  from  Marine  individual 
records  have  already  been  pushed  to  the  Web  via  MOL,  the 
key  is  for  Marines  to  have  the  ability  to  push  information 
back  . 

2 .  Level  2 :  Small  Unit  Leaders 


Figure  23  is  a 
scheme . 


diagram  of  the  level  2  execution 


Personnel 


Figure  23.  Small  Unit  Leaders  From  Ref.  [2] 

a.  Desired  End  State 

The  goal  for  small  unit  leadership  is  to  be  able 
to  input  Marine  training  information  into  the  system  while 
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providing  oversight  of  individual  Marine  transactions.  An 
abbreviated  version  of  UD/MIPS  should  be  in  place  so  that 
unit  leaders  do  not  have  to  become  experts  with  the  current 
UD/MIPS  that  requires  training  and  expertise  for 
information  input. 

b.  Figure  Depiction 

Small  unit  leaders  will  be  able  to  remotely 
capture  information  with  a  personal  electronic  device  (PED) 
similar  to  a  personal  digital  assistant  (PDA) .  The  PED  can 
upload  information  directly  into  MCTES  via  a  significantly 
scaled  down  and  abbreviated  version  of  UD/MIPS  designed  for 
non-administrators  or  the  full  version  of  UD/MIPS  located 
at  the  traditional  reporting  unit  level.  Transactions  can 
also  be  keyed  directly  into  the  UD/MIPS.  The  PEDs  can 
receive  downloads  from  the  small  unit  leaders  simplified 
UD/MIPS  or  complete  UD/MIPS,  and  allow  users  to  view  pay 
and  personnel  information  in  a  highly  portable 
configuration.  Small  unit  leaders  will  also  have  the 
capability  to  review  pay  and  personnel  information  on  their 
Marines .  [Ref .  2] 

c.  Analysis 

The  idea  is  to  use  PEDs  to  record  information  at 
training  events  and  then  go  back  and  hot-sync  the  PED  to  a 
computer  with  a  scaled  down  version  of  the  UD/MIPS.  This 
appears  to  be  a  great  idea,  but  there  is  little  information 
in  the  preliminary  documentation  that  discusses  how  this 
will  be  accomplished.  I  am  not  sure  how  feasible  an 
abbreviated  version  of  UD/MIPS  is  either. 
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3  .  Level  3 :  Battalion  and  Squadron  Commands 

a.  Desired  End  State 

Commanders  at  the  batt alion/squadron  and  above 
levels  will  retain  an  administrative  capability  to  collect, 
provide  quality  control  and  forward  personnel  and  pay- 
related  information  to  the  Personnel  Administration  Center 
(PAC)  for  final  processing.  This  will  be  primarily  focused 
on  command-originated  data,  but  the  capability  to  forward 
any  information  on  behalf  of  the  individual  Marine  will  be 
available.  These  administrators  will  also  review  feedback 
reports  on  data  submitted  to  a  PAC  by  individual  Marines 
via  Web  applications,  toll  free  telephone  services  or  the 
mail.  This  will  enable  the  commander  to  stay  informed  of 
the  changing  personnel  status  of  his  or  her  Marines.  The 
commander  will  have  electronic  access  to  pay  and  personnel- 
related  information  on  Marines  to  facilitate  situational 
awareness  and  unit-level  decision  making. 

b.  Figure  Depiction 

Figure  24  simply  shows  that  at  the  battalion  and 
squadron  level,  administration  will  be  conducted  the  same 
as  it  is  now.  The  only  changes  are  that  the  number  of 
transactions  that  will  be  processed  at  this  level  will  be 
significantly  streamlined.  The  squadron  or  battalion  will 
have  oversight  over  certain  functions  that  only  happen 
above  the  company  level  and  not  requiring  (PAC)  approval. 
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Figure  24.  Command  (Battalion  &  Squadron)  From  Ref.  [2] 

c.  Evaluation  of  Desired  End  State 

This  is  how  things  are  done  today  with  fewer 
transactions  and  responsibility.  I  see  no  problems  with 
acquiring  this  level  of  the  TFAS . 
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4 .  Level  4 :  Personnel  Administration  Center 

a.  Desired  End  State 

The  Marine  Corps  plans  on  establishing  a  minimum 
of  three  Personnel  Administration  Centers  (PACs) .  The 
consolidation  of  Marine  Corps  administrators  would 
eventually  end  at  the  PAC  level.  Administrators  would 
migrate  from  Regiment al /Groups  to  Division/Wing  and  then 
finally  to  base  or  PACs.  With  each  consolidation,  the 
number  of  administrators  required  to  handle  the 
administrative  would  be  the  level  at  which  Marine  Corps 
administrators  would  be  consolidated. 

b.  Figure  Depiction 

The  PAC  will  have  the  ability  to  receive 
traditional  reporting  via  the  UD/MIPS  in  addition  to 
processing  required  information  from  Marine  self-service. 
One  of  the  PACs  would  host  the  TFAS  call  center  for  handle 
all  call  center  functions.  A  second  call  center  would  be 
the  alternate  call  center  that  would  be  operated  when  the 
primary  call  center  was  inoperable.  Each  PAC  would  focus 
primarily  on  serving  Marines  whether  active  duty,  reserve, 
or  retired  in  their  region  of  responsibility.  However,  a 
PAC  could  process  information  on  any  Marine  during  times  of 
system  failure.  The  PAC  users  would  have  access  to 
information  in  the  operational  data  store  enterprise  (ODSE) 
database  . 
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Figure  25.  Personnel  Administration  Center  From  Ref.  [2] 

c.  Analysis 

The  PAC  is  the  key  to  the  success  of  the  TFAS 
initiative.  This  is  a  totally  new  level  that  incorporates 
most  of  the  administrative  responsibility  that  battalions 
and  squadrons  previously  held  plus  the  additional 
responsibility  of  handling  call  center  and  Web  input. 
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5. 


Level  5 :  Higher  HQ  and  Disbursing 


a.  Desired  End  State 

At  this  level  Manpower  and  Reserve  Affairs  will 
retain  functional  sponsorship  for  personnel  administration 
and  the  Deputy  Chief  of  Staff  for  Programs  and  Resources 
will  retain  functional  sponsorship  for  pay. 

b.  Figure  Depiction 

Figure  26  is  a  replica  of  the  level  four  diagram 
minus  the  call  center. 


Standalone 
UD/MIPS  * 


*  Can  operate  in  connected  or  disconnected  environment 


Figure  26.  Higher  HQ/Disbursing  From  Ref.  [2] 
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Administrators  at  this  level  would  not  perform  a  function 
in  the  direct  support  of  the  individual  Marine,  although 
pay  and  administration  functions  based  on  the  input  data 
into  the  system  would  occur  here.  This  is  also  the  level 
at  which  strategic  administrative  functions  would  occur, 
much  the  same  as  they  occur  today. 

c.  Analysis 

Nothing  changes  at  this  level.  All  relationships 
remain  virtually  the  same.  Responsibilities  for  oversight 
of  functions  do  not  change. 

D.  TRANSACTION  STATE  DIAGRAMS 

1 .  Analysis 

As  you  would  imagine,  there  are  not  many  differences 
between  the  "As-Is"  and  "To-be"  transaction  state  diagrams. 
Figures  27  and  28.  Simply  stated,  TFAS  is  simply  adding  an 
additional  front-end  to  the  current  system.  However,  there 
is  a  difference  in  the  two  diagrams.  The  first  difference 
is  that  in  the  "As-Is"  architecture  a  data  entry  must  be 
approved  prior  to  entry  into  the  system  whereas  with  the 
"To-be"  architecture  process  rules  must  be  coded  and 
installed  into  they  system  to  differentiate  between  entries 
that  must  be  approved  and  entries  requiring  no  approval. 
Additionally,  the  "As-Is"  diagram  appears  to  be  simpler  and 
more  timely  than  the  TFAS  transition  diagram,  but  it  does 
not  show  the  levels  of  bureaucracy  that  occur  between  an 
event  and  its  initial  entry  or  key  punch  into  the  system. 
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Figure  27.  "As  Is"  Transition  State  Diagram  From  Ref.  [2] 
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Figure  28.  "To  Be"  Transition  State  Diagram  From  Ref.  [2] 
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VI.  CONCLUSION  RECOMMENDATIONS 


A.  PROJECT  CONCEPTION 

The  TFAS  initiative  is  the  Marine  Corps  initiative  to 
reengineer  its  manpower  intensive  human  resource  system  by 
adding  an  individual  Marine  self-service  capability  to  the 
current  system.  It  is  envisioned  that  this  capability  will 
allow  the  Marine  Corps  to  increase  its  tooth  to  tail  ratio 
and  increase  the  level  of  customer  service  to  the 
individual  Marine.  This  thesis  evaluated  previous 
enterprise  system  implementations  searching  for  common 
mistakes  and  key  success  factors  that  could  be  applied  to 
the  TFAS  implementation.  As  stated  previously,  corporate 
and  military  human  resource  systems  are  similar  in 
functions  but  different  in  the  environments  in  which  they 
must  work.  Similar  functions  include  but  are  not  limited 
to:  insurance,  income  tax,  tuition  assistance,  pay  records, 
benefits,  and  audits.  The  differences,  operational  security 
and  bandwidth-limited  environments,  are  why  modularity, 
loose  coupling,  and  operational  security  must  be  built  into 
military  systems. 

B.  SUMMARY  OF  ANALYSIS 

All  of  the  TFAS  documentation  that  I  reviewed  focused 
on  getting  the  MCTFS  data  to  the  Web  and  on  giving  the 
Marine  access  and  responsibility  for  updating  some  of  that 
data.  None  of  the  documentation  talked  about  creating 
knowledge  or  increasing  the  decision  support  capability 
from  that  data,  an  aspect  normally  associated  with  an  ERP 
system.  Absent  in  the  documentation  is  talk  about  someday 
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linking  this  enterprise  information  system  to  other 
enterprise  systems  within  the  Marine  Corps  such  as  supply, 
recruiting,  etc.  Thus,  the  TFAS  initiative  in  all  reality 
has  the  appearance  of  more  of  an  e-business  (Web) 
implementation  rather  than  an  ERP  project. 

The  TFAS  leadership  characterized  their  overall 
strategy  for  proceeding  with  the  TFAS,  as  a  strategy  of  "do 
no  harm."  [Ref.  2]  As  the  documentation  in  this  thesis 
has  shown,  the  TFAS  initiative  represents  only  a  small  step 
or  enhancement  of  the  status  quo.  However,  this  small  step 
is  all  that  was  required  to  meet  the  original  goal  of  CMC 
to  decrease  the  ratio  of  administrators  to  Marines,  thus 
allowing  the  assignment  or  reassignment  of  more  Marines 
into  combat  arms  military  occupational  specialties  (MOSs) . 

Even  without  the  new  TFAS  front-end  and  customer 
service  center,  the  initiative  has  already  paid  dividends 
for  the  Marine  Corps.  The  TFAS  initiative  forced  the 
Marine  Corps  to  look  at  its  processes,  many  of  which  had 
not  been  modified  since  they  were  implemented  nearly  20 
years  ago  when  the  MCTFS  was  first  brought  online. 
Streamlining  the  processes  alone  has  allowed  the  Corps  to 
accomplish  its  goal  of  reducing  Corps-wide  the  number  of 
administrators  required  to  support  the  fleet.  Earlier  this 
year,  the  Marine  Corps  migrated  most  administration 
functions  and  administrators  from  the  squadrons  and 
battalions  to  the  Marine  Aircraft  Group  (MAG)  and 
regimental  level. 

A  successful  implementation  of  TFAS  will  see 
administration  functions  consolidated  at  the  Marine  Corps 
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Base  or  PAC  level.  Although  no  information  has  been 
provided  as  to  the  exact  number  of  administrators  that  can 
be  retrained  or  assigned  to  the  fleet  in  other  more 
critical  MOSs,  the  economies  of  scale  created  as 
administration  is  consolidated  at  higher  levels  should  be 
significant.  Also,  remember  that  1070  administrators  were 
reassigned  during  the  first  year  of  the  program,  and  we  can 
see  that  the  Corps  has  already  started  reaping  the  benefits 
of  the  Commandants'  vision.  The  TFAS  simply  attempts  to 
leverage  existing  technology  to  further  multiply  the 
manpower  and  cost  savings  while  introducing  the  customer 
service  concept  in  addition  to  the  old  focus  of 
functionality  to  Marine  Corps  administration. 

The  key  drivers  in  the  choices  made  in  the  TFAS 
planning  process  were  cost  and  risk.  The  initiative  as 
currently  defined  is  virtually  risk  free  and  at  a  projected 
cost  of  near  $30  million.  The  implementation  of  TFAS  over 
a  period  of  eight  years  allows  the  Marine  Corps  to  use 
money  that  would  normally  have  been  used  for  upgrades  to 
the  Unit  Diary/Manpower  Information  Processing  System 
(UD/MIPS),  thus  a  basic  reallocation  of  money.  The  TFAS  is 
also  a  cheaper  alternative  than  the  status  quo  over  a  five- 
year  period  according  to  Pr icewaterhouseCoopers 
calculations.  It  can,  however,  be  argued  that  for  the  same 
$30  million  or  less,  the  recommendations  of 
Pricewat erhouseCoopers  could  have  been  accomplished  in  a 
shorter  period  of  time.  Human  Resource  self-service 
technology  is  already  a  proven  technology  with  most 
corporate  implementations  having  few  or  little 
implementation  problems.  However,  most  corporations 
implement  self-service  technology  and  ERP  systems  to 
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achieve  the  maximum  gains  in  productivity  to  get  the  most 
return  on  investment . 

Looking  at  the  TFAS  documents  provided  and  reviewed 
for  this  thesis:  the  three  PricewaterhouseCoopers '  studies, 
the  Marine  Corps  Vision  and  End  State  document,  and  the 
preliminary  assessment,  it  is  not  possible  to  predict  with 
absolute  certainty  that  this  will  be  a  successful 
implementation.  I  see  no  problem  with  the  preliminary 
architecture;  the  diagrams  demonstrate  the  picture  of  the 
TFAS  as  expressed  in  the  TFAS  vision.  However,  some 
diagrams  were  missing  and  those  diagrams  present  were  all 
very  high-level  and  thus  do  not  portray  the  level  of  detail 
necessary  to  make  a  more  detailed  analysis.  The  TFAS  is  of 
limited  scope,  the  level  of  complexity  is  low  compared  to 
corporate  implementations,  and  call  center  and  Web-based 
portal  technology  is  mature,  thus  TFAS  appears  on  the  road 
to  success.  Additionally,  the  familiarities  of  the 
implementation  team  with  the  MCTFS,  the  UD/MIPS  and  the 
other  back-end  and  middleware  systems  currently  in-place, 
and  the  involvement  of  all  stakeholders  in  the 
implementation  process  are  all  complementary  to  the  TFAS 
implementation.  The  TFAS  implementation  appears  to  have  a 
solid  project  management  plan  based  on  a  balanced 
integration  plan. 

This  thesis  will  not  be  as  beneficial  to  the  TFAS 
leadership  as  it  would  have  been  if  the  study  had  been 
completed  prior  to  actual  execution  of  the  plan.  However, 
the  Marine  Corps  can  leverage  the  lessons  learned  from 
other  implementations  and  this  thesis  to  avoid  pitfalls 
that  could  be  lurching  in  the  projects  future.  Lessons 
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learned  from  corporate  implementations  can  be  beneficial  to 
the  TFAS  leadership.  However,  some  of  the  lessons  learned 
focus  on  a  time  prior  to  implementation  and  thus  can  only 
be  used  as  a  reflective  area  of  caution.  Some  of  these 
issues  will  be  further  developed  in  the  concerns  and 
recommendations  portion  of  this  thesis. 

My  study  shows  that  there  is  no  standard  set  of 
metrics  by  which  an  ERP  or  enterprise  system  implementation 
can  be  measured  a  success.  Success  or  failure  should  be 
defined  prior  to  implementation  by  the  goals  or  vision  for 
the  project.  Organizations  determine  their  own  metrics, 
such  as  cycle  time  and  Full  Time  Equivalent  (FTE's) 
improvements.  However,  in  a  military  organization,  a 
system  should  always  be  evaluated  for  its  impact  on 
operation  security,  something  that  could  be  overlooked  in  a 
human  resource  enterprise  implementation.  The  key  is 
whether  the  organizational  goals  and  vision  are  met. 
However,  the  organization  must  establish  a  baseline  of 
existing  process  metrics  to  compare  with  post-ERP  process 
metrics.  This  project  should  satisfy  the  stated  goals  of 
the  leadership. 

C.  CONCERNS  AND  RECOMMENDATIONS 

My  biggest  concern  with  the  TFAS  initiative  is  that 
the  Defense  Integrated  Military  Human  Resources  System 
appears  to  be  poised  to  duplicate  the  TFAS  effort.  If  this 
turns  out  to  be  the  case,  the  DIHMRS,  because  it  is  a  DoD 
initiative  will  have  precedence  over  the  TFAS.  Thus,  a  lot 
of  time  and  money  may  have  been  spent  needlessly.  Based  on 
the  description  of  TFAS  found  in  reference  three  as  quoted 
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earlier  there  will  definitely  be  a  duplication  of  function 
of  the  TFAS  and  the  DIHMRS.  A  second  issue  with  this 
duplication  is  the  possibility  that  the  MCTFS,  the  Marine 
Corp's  back  end  system,  will  not  be  addressed  as  part  of 
the  DIHRMS  initiative,  an  assumption  that  the  TFAS 
initiative  relies  on  heavily  in  its  preliminary  assessment. 

Another  concern  is  that  TFAS  leadership  has  proceeded 
with  the  TFAS  implementation  prior  to  designing  and 
finalizing  all  architectural  decisions.  One  of  the  key 
success  factors  from  Chapter  TV  says  do  not  start  on  any 
applications  until  the  architectural  design  has  been 
completed.  It  appears  that  the  TFAS  implementation  has 
violated  this  rule.  The  reason  giving  for  proceeding  with 
the  TFAS  implementation  prior  to  the  completed 
architectural  study  is  that  many  of  the  updates  and  actions 
fell  in  line  with  the  UD/MIPS  upgrades.  The  risk  of  doing 
this  is  that  the  TFAS  architecture  will  not  be  consistent 
and  that  integration  will  be  more  difficult  later  on  in  the 
TFAS  process.  The  architecture  is  the  foundation  of 
everything  that  happens  with  the  project,  and  this  alone 
introduces  considerable  risk  into  the  project.  Having  a 
technical  architecture  provides  many  benefits  to  the 
consistency  of  a  project,  including  as  mentioned  earlier  in 
the  thesis,  a  common  background  for  information  system 
personnel,  more  rapid  delivery  of  solutions,  and  reduced 
impact  of  change.  [Ref.  10] 

A  third  concern  for  the  TFAS  implementation  is  the 
lack  of  depth  of  explaining  some  of  the  concepts  of  how  the 
TFAS  will  work  with  PDAs/PEDs  and  be  programmed  for  use  at 
levels  two  and  three  to  be  able  to  input  information  into 
the  TFAS  system.  There  are  examples  in  industry  of 
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companies  using  PDAs  in  this  fashion;  however,  it  should 
not  be  assumed  that  this  would  be  an  easy  thing  to 
accomplish.  Will  we  contract  this  out  to  an  established 
contractor  or  will  it  be  done  in  house?  Does  PeopleSoft 
have  the  capability  to  accomplish  this  with  the  DIHRMS 
initiative?  These  are  all  questions  that  should  be 
answered.  Additionally,  what  is  the  concept  for  the  TFAS 
during  combat  operations  that  will  allow  the  TFAS  to 
support  OMFTS?  Will  we  rely  on  UD/MIPS  as  we  currently  do 
or  do  we  attempt  to  use  the  Internet  from  the  battlefield 
to  input  into  the  TFAS? 

There  is  little  discussion  as  to  who  will  create  the 
software  for  the  TFAS.  It  suggests  that  ITD-KCC  will 
create  the  software  applications  as  well  as  implement  the 
entire  project,  but  this  is  not  clear.  The  software  for  an 
enterprise  system  is  even  more  important  than  the  hardware, 
thus  I  would  like  to  have  seen  more  information  about  this 
in  the  preliminary  assessment.  As  defined  earlier  in 
chapter  two,  modularity  and  loose  coupling  should  be  used 
as  a  part  of  the  software  building  process.  The  goal 
should  be  for  the  system  to  be  interoperable  and  non¬ 
hardware  specific.  This  will  pay  dividends  in  the  future 
when  the  DIHMRS  migration  must  occur  and  when  hardware  is 
being  chosen  for  PEDs.  Additionally,  consideration  should 
be  given  to  how  the  system  will  work  in  bandwidth-limited 
environments,  such  as  on  ship.  Caching  could  be  built  into 
the  system  or  downloading  information  to  disks  to  make 
required  connection  to  the  server  as  limited  as  possible 
from  austere,  bandwidth-limited  situations. 

There  are  other  issues  that  have  less  to  do  with  the 
TFAS  and  more  with  PeopleSoft  who  has  received  the  DIHMRS 
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contract.  PeopleSoft  is  being  sued  by  a  subsidiary  of 
CIGNA  Corp,  Connecticut  General  Life  Insurance  Company. 
PeopleSoft  is  being  accused  of  botching  the  ERP  software 
development  and  failure  to  properly  implement  the  system. 
[Ref.  9]  PeopleSoft  stated  [Ref.  9],  "It  is  unfortunate 
that  for  internal  reasons,  CIGNA  was  unable  successfully  to 
adopt  our  software,  but  this  was  not  related  to  the  quality 
of  the  software  or  services  provided  by  PeopleSoft."  I 
would  recommend  that  the  Marine  Corps  push  PeopleSoftS 
(DIHRMS)  migration  back  until  it  has  been  successfully 
deployed  in  the  other  services.  Since  the  Marine  Corps  has 
already  proceeded  with  the  TEAS,  if  DIHMRS  migration  proves 
to  be  unsuccessful  in  other  parts  of  DoD,  the  Marine  Corps 
can  fall  back  on  the  TEAS  and  delay  migration  until  the 
problems  have  been  worked  out. 

PeopleSoft  is  a  company  that  is  growing  quickly. 
Some  question  their  ability  to  sustain  this  growth  and 
support  all  of  their  responsibilities.  With  the  size  and 
complexity  of  DoD,  PeopleSoft  might  have  problems  with  the 
DIHMRS  migration.  PeopleSoft  has  won  several  high  profile 
contracts  in  recent  months  to  include  the  IRS  and  the 
DIHRMS  contract  both  of  which  have  been  promised  product 
delivery  within  one  year.  PeopleSoft  has  2000  current 
customers  who  have  requested  upgrades  to  PeopleSoft  8,  of 
which  only  200  have  been  upgraded  as  of  September  1,  2001 
and  projections  of  only  an  additional  500  being  up  and 
running  by  next  year.  Delaying  implementation  until  the 
end  will  be  a  good  risk  mitigation  strategy  for  the  Marine 
Corps.  It  is  too  late  for  the  TEAS  project  to  completely 
change  direction.  Therefore,  if  I  were  the  program  manager 
for  the  TEAS  project,  I  would  proceed  with  the  project  as 
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planned  but  tread  cautiously.  I  would  come  up  with  a 
contingency  plan  to  address  the  MCTFS  as  a  risk  mitigation 
strategy  just  in  case  this  thesis  is  correct  that  DIHMRS 
and  TFAS  do  duplicate  effort.  I  would  perform  a  second 
review  of  the  TFAS  architecture  study  to  ensure  the  TFAS 
applications  are  built  on  a  solid  basis. 


D.  Further  Research 

There  was  not  enough  information  available  to  conduct 
a  thorough  analysis  of  the  TFAS  architecture.  The  TFAS 
leadership  may  have  already  negotiated  many  of  the  concerns 
discussed  in  this  thesis.  I  am  sure  that  there  is  more 
documentation  that  I  was  not  privy  to  that  could  lend  more 
credibility  to  a  concern  or  provide  the  answers  to 
questions  that  would  make  the  concern  invalid.  Research 
should  be  conducted  on  a  comparison  of  the  DIHMRS  and  the 
TFAS  to  determine  if  the  assumptions  of  the  TFAS  leadership 
that  TFAS  is  addressing  areas  different  from  the  TFAS  and 
that  the  DIHMRS  will  address  the  back  end  systems  neglected 
by  the  TFAS  are  indeed  true.  Until  this  is  accomplished,  I 
think  it  is  futile  to  study  other  areas  of  the  program. 

However,  once  this  has  been  completed  the  other  areas 
that  could  benefit  from  further  research  are  a  review  of 
any  official  technical  architecture  that  goes  beyond  the 
preliminary  documents  reviewed  in  this  thesis  would  be 
beneficial.  The  study  of  the  security  features  of  the 
TFAS  and  the  communications  platform  are  all  areas  ripe  for 
study.  A  study  of  what  it  would  take  for  the  Marine  Corps 
to  have  a  truly  integrated  enterprise,  e.g.,  tie  supply, 
finance,  human  resource,  all  to  one  system  where  data  from 
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anywhere  could  be  moved  anywhere  in  the  enterprise  is 
another  area  for  study. 

Additionally,  some  type  of  comparison  should  be  done 
to  determine  whether  the  quality  of  service  to  the 
individual  Marine  actually  increases  or  decreases  because 
of  the  TFAS  implementation.  In  the  short  term  there  will 
probably  be  some  degradation  of  service,  especially  during 
the  period  prior  to  Marine  self-service  coming  online  when 
administration  is  being  consolidated  at  higher  levels. 
Capturing  and  applying  the  lessons  learned  from  the  TFAS 
implementation  to  the  DIHRMS  implementation  and  future 
human  resource  implementations  are  areas  that  should  also 
be  considered. 
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